IAB Rel-17

 RAN1#102-e

8.10   Enhancements to Integrated Access and Backhaul

Please refer to RP-201293 for detailed scope of the WI

R1-2007388        Session notes for 8.10 (Enhancements to Integrated Access and Backhaul)   Ad-hoc Chair (Samsung)

R1-2006824         Workplan for Rel-17 IAB  Qualcomm Incorporated

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2005467        Enhancements to the IAB resource multiplexing    ZTE, Sanechips

·        Proposal 1: The similar semi-static resource partitioning scheme to Rel-16 mechanism of CU time-domain H/S/NA configuration can be the starting point of resource partitioning scheme in frequency domain.

·        Proposal 2: To de-prioritize simultaneous DU-Tx/MT-Rx, DU-Rx/MT-Tx and DU-Tx/MT-Tx in RAN1 Rel-17 normative work.

o   The above three duplex operations can still be implemented in practice, e.g., by using multi-panel antenna and separate PA to isolate the DU-Tx/Rx and MT-Tx/Rx in their analog forms. In this case, there is no FDM/SDM relation in between per RAN1 perspective.

Decision: The document is noted.

R1-2006165        Enhancements to Resource Multiplexing for NR IAB           Samsung

·        Proposal 1: For simultaneous operations of an IAB node with benefits of spectral efficiency and latency, RAN1 should provide spec. supports to allow efficient operations considering implementation limitations such as near-field channel estimation for interference handling.

·        Proposal 2: As a baseline, consider dual connectivity scenarios with two parent nodes under same IAB-donor in Rel-17.

·        Proposal 3: Discuss whether or not separate signaling between IAB MT and different parent IABs are necessary in Rel-17.

·        Proposal 4: Discuss how to address scheduling collision issues for child IAB between MCG and SCG.

Decision: The document is noted.

R1-2006825         Resource management for enhanced duplexing           Qualcomm Incorporated

R1-2006903         IAB enhancements to resource multiplexing Ericsson

R1-2005260         Resource multiplexing between backhaul and access for IAB duplexing enhancements      Huawei, HiSilicon

R1-2005399         Enhancement to resource multiplexing between child and parent links   vivo

R1-2005535         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2005893         Enhancements to Resource Multiplexing between Child and Parent Links of an IAB Node      Intel Corporation

R1-2005927         Enhancements to resource multiplexing for IAB         Lenovo, Motorola Mobility

R1-2005951         Enhancements for IAB resource multiplexing             AT&T

R1-2006228         Discussion on resource multiplexing in the simultaneous operation        CMCC

R1-2006329         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

R1-2006361         Discussion on IAB resource multiplexing enhancements          ETRI

R1-2006382         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2006744         Resource multiplexing between child and parent links of an IAB node   NTT DOCOMO, INC.

[102-e-NR-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node by 8/28

-        Prioritize topics to be resolved in RAN1#102-e by 8/19

R1-2007241        Summary #1 of [102-e-NR-eIAB-01]          Moderator (AT&T)

Conclusion

At least the inter-carrier DC scenario can be considered in Rel-17. Further discussion in RAN3/RAN Plenary may be necessary for the intra-carrier DC scenario.

Agreement

Reuse by IAB-MT of existing Inter-frequency DC is considered as a starting point to support concurrent BH links to two parents.

·        FFS: Reuse of multi-TRP transmission resource allocation features (if intra-freq DC scenario is supported for IAB)

·        FFS: Additional specification effort to support IAB

For companies to further consider:

The following categories of enhancements have been proposed to support DC scenarios (not an exhaustive list):

·        Inter-parent DU resource coordination mechanisms and signaling

·        Resource allocation/scheduling conflict resolution rules at the parent or child node

·        Per-link IAB-DU resource configurations at the parent node

Agreement

At least existing Rel-16 bands supporting IAB can be considered when evaluating the feasibility/impact of supporting different multiplexing cases.

R1-2007322        Summary #2 of [102-e-NR-eIAB-01]          Moderator (AT&T)

From GTW session on August 28^th,

Agreement

The Rel-16 semi-static and dynamic resource allocation mechanisms are the starting point for supporting Rel-17 multiplexing cases.

·        FFS: Applicability for different IAB-DU resource types

·        FFS: Cell-specific/semi-static signals and channels at the IAB-DU and/or IAB-MT

Agreement

·        Based on the WID, the following multiplexing cases are in scope for potential support in Rel-17:

o   Multiplexing Case A: Simultaneous MT-Tx/DU-Tx

o   Multiplexing Case B: Simultaneous MT-Rx/DU-Rx

o   Multiplexing Case C: Simultaneous MT-Rx/DU-Tx

o   Multiplexing Case D: Simultaneous MT-Tx/DU-Rx

·        Further study for for Case A and Case B at least the following scenarios:

o   Single or multi-panel IAB nodes operating in unpaired spectrum (FR1 and FR2 bands)

·        Further study for Case C and Case D at least for the following scenarios:

o   Multi-panel IAB nodes operating in unpaired spectrum (FR1 and FR2 bands)

·        FFS: Required level of specification impact to support the different cases. Any additional specification support in Rel-17 should be conditioned on feasibility from an interference and reliability perspective on a per-link and network basis

For companies to further consider:

Whether the following characteristics of the IAB node implementation will impact the operation of different resource multiplexing cases, including resource partitioning (i.e. identify whether there is a need for potential specification impact/enhancements compared to Rel-16 if the characteristic is or is not supported by an IAB node):

·        Baseband (mis)timing alignment between IAB-MT and IAB-DU

·        Separate vs. shared antenna panels/RF front-end for IAB-MT/IAB-DU

·        Separate vs. shared baseband for IAB-MT/IAB-DU

·        Transmitter/receiver implementation

·        Self-interference cancellation

·        Power control mechanisms

For companies to further consider:

Different resource partitioning scenarios for access and backhaul links, including their respective implication on interference, for different resource multiplexing cases. Examples include:

·        Whether a given case is only applicable for certain resource types: e.g. DL only, UL only, DL + UL

·        Whether a given case is only applicable for backhaul links or both access and backhaul links

·        Note: This should have no impact on legacy UE behavior

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed

R1-2005261        Enhancements for simultaneous operation of MT and DU   Huawei, HiSilicon

·        Proposal 1: Case #6 timing should be supported to mitigate interference in MT Tx/DU Tx scenario.

·        Proposal 2: Case #7 timing need to be supported for IAB to enabling better interference mitigation for simultaneous reception.

·        Proposal 3: A Case #7-like timing mode can be adopted to enhance self-interference cancelation in UL full-duplex.

·        Proposal 4: Enhancements on power control should focus on IAB MT.

·        Proposal 5: Enhancements on CLI to support the simultaneous operation of IAB MT and DU including inter-multiplexing chain scenarios, at least should consider

o   Interference measurement

o   Interference coordination/management

·        Proposal 6: To handle various types of interference, regardless of interference source is MT or DU, a unified CLI measurement and management framework can be adopted in IAB.

Decision: The document is noted.

R1-2005536         Other enhancements for simultaneous operation of IAB Parent and Child               Nokia, Nokia Shanghai Bell

R1-2005952         Enhancements for IAB interference management        AT&T

R1-2006745         Other enhancements for simultaneous operation of IAB-node’s child and parent links               NTT DOCOMO, INC.

R1-2005400         Other enhancements for simultaneous operation of child and parent links             vivo

R1-2005468         Enhancements for simultaneous operation of child and parent links        ZTE, Sanechips

R1-2005544         Timing alignment for simultaneous operation of IAB-node’s child and parent links               Fujitsu

R1-2005894         Discussion on IAB Backhaul DL Power Control         Intel Corporation

R1-2005928         Enhancements for simultaneous operation in IAB systems       Lenovo, Motorola Mobility

R1-2006166         Enhancements to Timing, Power Control and CLI for NR IAB Samsung

R1-2006229         Discussion on the enhancement for simultaneous operation      CMCC

R1-2006383         Discussion on Other Enhancements for Simultaneous Operation             LG Electronics

R1-2006581         Power Control: It’s an Enhancement, and Here’s Our Views    Sharp

R1-2006826         On enhancements for simultaneous operation of IAB-node's child and parent links               Qualcomm Incorporated

R1-2006904         Other enhancements for simultaneous child and parent link operation in IAB               Ericsson

[102-e-NR-eIAB-02] – Luca (Qualcomm)

Email discussion non other enhancements for simultaneous operation of IAB-node’s child and parent links by 8/28

-        Prioritize topics to be resolved in RAN1#102-e by 8/19

R1-2007287        Summary of [102-e-NR-eIAB-02] Moderator (Qualcomm)

R1-2007310         Summary#2 of [102-e-NR-eIAB-02]             Moderator (Qualcomm)

Agreement

• Case 7 timing is supported in Rel-17 for IAB-nodes operating in multiplexing scenario Case 2 (simultaneous MT-Rx/DU-Rx)

• Case 6 timing is supported in Rel-17 for IAB-nodes operating in multiplexing scenario Case 1 (simultaneous MT-Tx/DU-Tx)
• RAN1 should strive to minimize specification impact due to this feature
• FFS: Whether Case 7 timing is supported in Rel-17 for IAB-nodes operating in multiplexing scenario Case 4 (simultaneous MT-Tx/DU-Rx)

Final summary in:

R1-2007352        Summary#3 of [102-e-NR-eIAB-02]           Moderator (Qualcomm)

8.10.33     Other

R1-2005401         Other enhancements to Rel-17 IAB nodes     vivo

R1-2005953         Measurement results for IAB multi-panel transmission and reception    AT&T

R1-2006384         Discussion on RACH procedure for IAB enhancement             LG Electronics

R1-2006403         Considerations on enhancement of guard symbols for IAB       Huawei, HiSilicon

R1-2006622         SDM scheme and antenna configuration for IAB node              ZTE, Sanechips

R1-2006905         Enhancements to IAB for NR – overview of Rel-17 WI            Ericsson

 RAN1#103-e

8.10   Enhancements to Integrated Access and Backhaul

Please refer to RP-201293 for detailed scope of the WI

R1-2009837        Session notes for 8.10 (Enhancements to Integrated Access and Backhaul)   Ad-hoc Chair (Samsung)

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2007594         Resource multiplexing between backhaul and access for IAB duplexing enhancements      Huawei, HiSilicon

R1-2007684         Enhancement to resource multiplexing between child and parent links   vivo

R1-2008029         Discussion on resource multiplexing in the simultaneous operation        CMCC

R1-2008184         Enhancements to Resource Multiplexing for NR IAB Samsung

R1-2008312         Enhancements for IAB resource multiplexing             AT&T

R1-2008406         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2008858         Enhancements to the IAB resource multiplexing         ZTE, Sanechips

R1-2008863         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2008995         Enhancements to Resource Multiplexing between Child and Parent Links of an IAB Node      Intel Corporation

R1-2009108         Enhancements to resource multiplexing for IAB         Lenovo, Motorola Mobility

R1-2009190         Resource multiplexing between child and parent links of an IAB node   NTT DOCOMO, INC.

R1-2009220         Discussion on IAB resource multiplexing enhancements          ETRI

R1-2009221         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

R1-2009269         Resource management for enhanced duplexing           Qualcomm Incorporated

R1-2009301         Resource multiplexing and DC in enhanced IAB         Ericsson

[103-e-NR-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node

• 1^st check point: 11/5
• 2^nd check point: 11/10
• 3^rd check point: 11/12

R1-2009604        Summary #1 of [103-e-NR-eIAB-01]          Moderator (AT&T)

Decision: From GTW session on Nov 5^th,

Agreement

The Rel-16 IAB-DU resource types (Soft/Hard/NA) are the starting point for supporting resource multiplexing for simultaneous operation cases in Rel-17.

·        FFS: Whether resource type definitions need to be extended to frequency domain resources

·        FFS: Coexistence of simultaneous operation resources and TDM resources

·        FFS: Whether new rules governing cell-specific/semi-static signals and channels at the IAB-DU and/or IAB-MT in case of simultaneous operation are necessary

Agreement

Further consider different applicability restrictions/conditions for simultaneous operation multiplexing cases:

·        FFS: Whether a given case is only applicable for certain resource types or combinations: e.g. DL access, DL backhaul, UL access, UL backhaul

·        FFS: Network (including parent node) awareness of a child IAB node’s ability to support simultaneous operation due to short-term and long-term factors including panel selection, interference, timing, transmit power, capability indication etc.

·        FFS: Necessary differentiation for paired spectrum vs. unpaired spectrum

·        FFS: Whether specific enhancements are defined for full-duplex cases vs. being left to implementation (as in Rel-16)

·        Note: There should not be any impact on legacy UE behavior

R1-2009734        Summary #2 of [103-e-NR-eIAB-01]          Moderator (AT&T)

Decision: From GTW session on Nov 12^th,

Agreement

The Rel-16 explicit indication of soft resources by DCI Format 2_5 is supported for simultaneous operation cases in Rel-17.

·        FFS: Whether/how to extend DCI Format 2_5 to frequency domain resources and/or paired spectrum

·        FFS: Coexistence of simultaneous operation resources and TDM resources

Agreement

From a RAN1 perspective, at least intra-donor multi-parent operation is supported in Rel-17

·        FFS: Inter-donor operation pending additional input from RAN2/RAN3

Agreement

The explicit indication of soft resources by DCI Format 2_5 is supported for multi-parent scenarios in Rel-17.

·        FFS: Whether additional enhancements over the Rel-16 solution are needed

Agreement

From a RAN1 perspective, resource multiplexing and coordination is supported for the following DC scenarios in Rel-17.

·        Inter-carrier, inter-band

·        Inter-carrier, intra-band is additionally supported at least for FR2

o   At least to the extent it reuses solutions for supporting Inter-carrier, inter-band

o   FFS: whether specific enhancements for inter-carrier, intra-band DC are introduced in Rel-17

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed

R1-2007595         Enhancements for simultaneous operation of MT and DU         Huawei, HiSilicon

R1-2007685         Other enhancements for simultaneous operation of child and parent links             vivo

R1-2007786         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Fujitsu

R1-2008030         Discussion on the enhancement for simultaneous operation      CMCC

R1-2008185         Enhancements to Timing, Power Control and CLI for NR IAB Samsung

R1-2008313         Enhancements for IAB interference management        AT&T

R1-2008407         Discussions on other enhancements for simultaneous operation              LG Electronics

R1-2008816         Discussion on simultaneous operation of IAB-node’s child and parent links               CEWiT

R1-2008859         Enhancements for simultaneous operation of child and parent links        ZTE, Sanechips

R1-2008864         Other enhancements for simultaneous operation of IAB Parent and Child               Nokia, Nokia Shanghai Bell

R1-2008996         Power Control Enhancements for Simultaneous Operations      Intel Corporation

R1-2009019         Discussion on simultaneous operation enhancements ETRI

R1-2009109         Enhancements for simultaneous operation in IAB systems       Lenovo, Motorola Mobility

R1-2009137         Power Control: Subsequent Contribution      Sharp

R1-2009191         Other enhancements for simultaneous operation of IAB-node’s child and parent links               NTT DOCOMO, INC.

R1-2009270         On enhancements for simultaneous operation of IAB-node's child and parent links               Qualcomm Incorporated

R1-2009302         Timing, CLI and power control in enhanced IAB        Ericsson

[103-e-NR-eIAB-02] – Luca (Qualcomm)

Email discussion non other enhancements for simultaneous operation of IAB-node’s child and parent links

• 1^st check point: 11/5
• 2^nd check point: 11/10
• 3^rd check point: 11/12

R1-2009567        Summary #1 of [103-e-NR-eIAB-02]          Moderator (Qualcomm)

Decision: From GTW session on Nov 4^th,

Agreement

Select one or both of the following modes of operation for Case 7 timing in RAN1#104-e:

·        symbol level alignment without slot level alignment

·        slot level alignment

Decision: As per email decision posted on Nov 9^th,

Agreement

Case 6 timing mode operation at an IAB-node is controlled by the parent node to which the UL transmission is intended for.

Agreement

Use the Rel-16 interference management frameworks (e.g. CLI, RIM) to handle IAB interference scenarios, and discuss if any of the following enhancements are needed (not an exhaustive list):

·        FFS: extend the information exchange (e.g. the resource configuration, result of CLI measurements, etc.) among different entities (e.g. between parent-child nodes, adjacent IAB nodes, between network and IAB-node, etc.)  

·        FFS: required enhancements on CLI measurement accuracy (e.g. via timing adjustment, etc.)

·        FFS: required enhancements on CLI measurements (e.g. introducing short-term measurements, multi-beam measurements, etc.)

Agreement

Further study requirement of enhanced DL and UL Tx power control mechanism considering the following: 

·        DL/UL power control with assistance information from the child node.

·        DL/UL power control with assistance information from the parent node.

·        Central (e.g. by CU) power control coordination (e.g. semi-static max DL/UL Tx power limits).

·        Coexistence of different power control mechanisms within an IAB node and in the network.

Note. Any power control mechanism should consider the following aspects:

·        Existing base station design principles (e.g. power control and dynamic range capability, etc.) related to transmission power.

·        Network constraints in regard to transmitted reference signals with constant power.

R1-2009709        Summary #2 of [103-e-NR-eIAB-02]          Moderator (Qualcomm)

Decision: From GTW session on Nov 12^th,

Agreement

Interference management for the following IAB interference scenarios should be discussed:

·        Inter-IAB scenarios, including:

o   MT to MT, DU to DU, DU to MT, and MT to DU.

·        Interference to non-IAB nodes, including:

o   IAB-DU to non-IAB-DU

o   IAB-MT to non-IAB-DU

·        Intra-IAB-node (self-interference) scenarios (Interference between a DU and MT of an IAB-node).

This agreement does not necessarily mean that specification support is needed for any of the scenarios.

Agreement

Consider resource and beam coordination techniques to mitigate/avoid interference, including (not an exhaustive list):

·        FFS: whether or not to support IAB‐node (MT) transmissions in DL access slots

o   FFS: if this has RAN1 impact or it can be handled by implementation.

o   FFS: network coordination impact

·        FFS: whether Rel-16 resource management framework is sufficient.

R1-2009765        Summary #3 of [103-e-NR-eIAB-02]          Moderator (Qualcomm)

Decision: From GTW session on Nov 13^th,

Agreement

An IAB-node can rely on an OTA timing synchronization mechanism to enable/maintain Case 6 timing mode

·        FFS whether the Rel-16 OTA synchronization mechanism is sufficient or enhancements are required

o   If required, details of enhancements including the uplink timing(s) required to support different timing alignment cases

Decision: As per email decision posted on Nov 13^th,

Agreement

An IAB-node, when operating in Case 7 timing mode, can enable a child node to set its DL Tx timing based on Rel-16 OTA timing synchronization mechanism.

·        FFS whether Rel-16 OTA synchronization mechanism enhancements are required

o   FFS details of enhancements, if required

8.10.33     Other

R1-2007686         Other enhancements to Rel-17 IAB nodes     vivo

R1-2008314         Performance of simultaneous operation of IAB-node’s child and parent links               AT&T

R1-2008327         Other enhancements for IAB           Huawei, HiSilicon

R1-2008408         Discussion on RACH procedure for IAB enhancement             LG Electronics

R1-2008860         Discussion on multiplexing capability for IAB            ZTE, Sanechips

R1-2009020         Other enhancements to IAB             ETRI

R1-2009303         Refined beam calibration in enhanced IAB   Ericsson

 RAN1#104-e

8.10   Enhancements to Integrated Access and Backhaul

Please refer to RP-201293 for detailed scope of the WI

R1-2102196        Session notes for 8.10 (Enhancements to Integrated Access and Backhaul)   Ad-hoc Chair (Samsung)

R1-2101482         Workplan for Rel-17 IAB  Qualcomm Incorporated

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2100219         Resource multiplexing between backhaul and access for IAB duplexing enhancements      Huawei, HiSilicon

R1-2100463         Enhancement to resource multiplexing between child and parent links   vivo

R1-2100670         Enhancements to Resource Multiplexing between Child and Parent Links of an IAB Node      Intel Corporation

R1-2100690         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

R1-2100717         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2100777         Enhancements for IAB resource multiplexing             AT&T

R1-2100833         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2100958         Enhancements to the IAB resource multiplexing         ZTE, Sanechips

R1-2100990         Resource multiplexing in enhanced IAB systems        Lenovo, Motorola Mobility

R1-2101083         Discussion on IAB resource multiplexing enhancements          ETRI

R1-2101227         Enhancements to Resource Multiplexing for NR IAB Samsung

R1-2101483         Resource management for enhanced duplexing           Qualcomm Incorporated

R1-2101628         Resource multiplexing between child and parent links of an IAB node   NTT DOCOMO, INC.

R1-2101695         Resource multiplexing and DC in enhanced IAB         Ericsson

R1-2101855        Summary #1 of [104-e-NR-eIAB-01]          Moderator (AT&T)

[104-e-NR-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node

-        1^st check point: Jan 27

-        2^nd check point: Feb 1

-        3^rd check point: Feb 5

Including the response LS to R1-2100004 till Feb 1^st.

Agreement

Send LS response to RAN3 that both inter-donor multi-parent scenarios (Scenario 1 and Scenario 2) can be supported in Rel-17 with support for inter-donor resource coordination (e.g. DU H/S/NA and DL/UL resource configurations) in RAN3 specification.

·        LS to be drafted by Seunghoon (Samsung)

R1-2101889        Summary of [104-e-NR-eIAB-01] – 1st Checkpoint Moderator (AT&T)

R1-2101880        Reply LS on inter-donor topology redundancy       RAN1, Samsung

Decision: The LS is approved.

Agreement

Support indication/reporting of information between an IAB node and its parent node to assist in the determination of the applicability of a given multiplexing capability in case of simultaneous operation. The following solutions are considered (other solutions not precluded):

• Temporal applicability of a given multiplexing capability
• Time/frequency resource restrictions (e.g. access vs. backhaul links, DL vs. UL resources)
• Indications of conditions/reporting information required to realize the given multiplexing capability, (e.g. timing mode, power control, guard symbols, etc.)

FFS: channels/signals used for indicating/reporting information

R1-2101890        Summary of [104-e-NR-eIAB-01] – 2nd Checkpoint             Moderator (AT&T)

Decision: As per email posted on Jan 30^th,

Agreement

Further study whether/how to manage resources in the spatial domain. Candidate solutions are:

• Dynamic signaling between parent and child nodes for using/restricting/sharing antenna panels/beams
• Beam management / multi-panel enhancements for simultaneous operations
• Extension of H/S/NA resource indication to the spatial domain

Other solutions are not precluded.

Agreement

Regardless of simultaneous operation, the same cell-specific/semi-static signals and channels of the IAB-DU considered as hard time/frequency resources in Rel-16 are also considered as hard time/frequency resources in Rel-17.

·        FFS: IAB-MT behavior in case of conflicts between cell-specific signals/channels and other resource configurations of the IAB-MT (e.g., dedicated slot configurations)

Agreement

The following are considered to support at least inter-band inter-carrier scenarios in Rel-17:

• Solutions to address resource coordination/scheduling collision issues between parent nodes including TDD configurations and resource type indications at least in case of intra-donor CU multi-parent scenarios
• Consider Rel-16 CA framework as starting point
• Solutions for scheduling collision between two parent DUs due to indication of the resource availability for soft symbol(s) to the IAB-DU(s) by DCI format 2_5
• Solutions for scheduling collision between two parent DUs due to indication of the slot format by DCI format 2_0
• FFS: Whether or not separate solutions are required for resource coordination in case of inter-donor CU multi-parent scenarios
• Per-backhaul link (e.g. per child IAB-MT link) resource configurations in addition to per-DU resource configurations
• FFS: Enhancements to indication of soft resource availability from child node to parent node(s)
• FFS: Additional restrictions on simultaneous operation and/or multiplexing
• FFS: Whether the above solutions are also applicable for intra-band inter-carrier scenarios and whether additional solutions are required (e.g. RAN2 and RAN4 work related to adding band configuration and RRM requirements for intra-band inter-carrier NR-DC or updating related UE/MT capabilities for NR-DC so that they are applicable for intra-band inter-carrier NR-DC)

R1-2101891        Summary of [104-e-NR-eIAB-01] – 3rd Checkpoint             Moderator (AT&T)

Agreement

Further consider until RAN1#104bis-e whether to support the extension of the semi-static DU resource type indication to frequency-domain resources within a carrier (in addition to existing Rel-16 per-carrier granularity) for H/[S]/NA resource types, including the following aspects:

• Granularity for frequency domain resources within a carrier (starting point is a set of N RBs with FFS: value of N >=1)
• Relationship with Rel-16 DU resource type indications in case of coexistence between TDM and FDM operation, including time-granularity of switching between multiplexing options to ensure backwards compatibility with Rel-16 IAB nodes and avoid impact on access UEs and their RRC configurations at CU
• In case frequency-domain extension is supported for soft resources, enhancements for DCI format 2_5 to support dynamic indication of availability for soft frequency resources.

o   Alt. 1 Separate indication of time and frequency resources

§  FFS: different field, RNTI or different DCI

o   Alt. 2 Joint indication of time and frequency resources

§  FFS: backwards compatibility with Rel-16

• FFS: Extension of FDM across carriers
• FFS: Restrictions on band/minimum bandwidth for FDM operation (e.g. FR2 100MHz+ etc.)

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed

R1-2100220         Enhancements for simultaneous operation of MT and DU         Huawei, HiSilicon

R1-2100464         Other enhancements for simultaneous operation of child and parent links             vivo

R1-2100671         Other Enhancements for Simultaneous Operations     Intel Corporation

R1-2100718         Discussions on other enhancement for simultaneous operation LG Electronics

R1-2100744         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Fujitsu

R1-2101810         Enhancements for IAB interference management        AT&T    (rev of R1-2100778)

R1-2100834         Other enhancements for simultaneous operation of IAB Parent and Child               Nokia, Nokia Shanghai Bell

R1-2100955         Discussion on simultaneous operation of IAB-node’s child and parent links               CEWiT

R1-2100959         Enhancements for simultaneous operation of child and parent links        ZTE, Sanechips

R1-2100991         Timing, interference, and power control in enhanced IAB systems         Lenovo, Motorola Mobility

R1-2101084         Discussion on simultaneous operation enhancements for eIAB ETRI

R1-2101228         Enhancements to Timing, Power Control and CLI for NR IAB Samsung

R1-2101484         On enhancements for simultaneous operation of IAB-node's child and parent links               Qualcomm Incorporated

R1-2101629         Other enhancements for simultaneous operation of IAB-node’s child and parent links               NTT DOCOMO, INC.

R1-2101696         Timing, CLI and power control in enhanced IAB        Ericsson

[104-e-NR-eIAB-02] – Luca (Qualcomm)

Email discussion on other enhancements for simultaneous operation of IAB-node’s child and parent links

-        1^st check point: Jan 27

-        2^nd check point: Feb 1

-        3^rd check point: Feb 5

R1-2101878        Summary #1 of [104-e-NR-eIAB-02]          Moderator (Qualcomm Incorporated)

Agreement

Case 7 timing is supported with symbol level alignment without explicit support for slot level alignment

Decision: As per email posted on Jan 29^th,

Agreement

Switching between Case 1, Case 6, and Case 7 timing is supported.

• FFS whether Case 6 and Case 7 timing shall be restricted to certain resources, e.g. excluding resources used for access or TDM backhaul
• FFS details on switching including the switching conditions
• FFS relationship between switching timing modes with the usage/indication of different resource multiplexing modes
• FFS whether Rel-16 OTA synchronization shall be enhanced to support switching timing modes

R1-2102031        Summary #3 of [104-e-NR-eIAB-02]          Moderator (Qualcomm Incorporated)

Agreement

RAN1 to further study whether the legacy UL power control mechanism (including PHR) is sufficient for an IAB-node operating in an enhanced multiplexing mode.

·        FFS: if not (i.e., the legacy mechanism is not sufficient), support an IAB-node indicating information to assist with its UL power control.

Agreement

Support an IAB-node indicating information to assist with the DL power control of its parent-node towards the IAB-node without mandating an expected behavior at the parent node.

·        Note: At least the assistance information is for supporting the simultaneous operation within the IAB-node to avoid power imbalance

·        FFS: type of assistance information (e.g., desired received power, power adjustment, preferred CSI-RS resource)

·        FFS: whether this information is provided to the parent-node, the CU, or both.

·        FFS: applicability of the assistance information (e.g. relation to beams or multiplexing modes)

·        FFS: the channel carrying this assistance information

Conclusion

In Rel-17, RAN1 will not specify specific mechanisms for intra-IAB-node interference (self-interference) management.

·        Self-interference can be handled by the implementation or via using the available techniques defined, or to be defined in Rel-17, that can commonly be used for other interference scenarios as well.

R1-2102172        Summary #4 of [104-e-NR-eIAB-02]          Moderator (Qualcomm)

Agreement

RAN1 to select among the following options to support DU-to-DU measurement and report.

·        For DU-to-DU CLI measurement:

o   Option 1.1. no specific mechanism is specified (e.g., it is handled by the implementation, or the available techniques)

o   Option 1.2. enhanced legacy DU-based measurement procedures (e.g., enhanced Rel-16 RIM)

o   Option 1.3. enhanced MT-based measurements (e.g., MT-based CLI, MT RRM measurements)

·        For DU-to-DU CLI report:

o   Option 2.1. no specific mechanism is specified (e.g., it is handled by the implementation, or the available techniques)

o   Option 2.2. enhanced legacy DU-based report (e.g., enhanced Rel-16 RIM)

o   Option 2.3. enhanced MT-based report (e.g., MT-based CLI, MT RRM measurements)

Agreement

RAN1 to decide whether to enhance interference mitigation through information exchange to support beam-management at the parent or child node in RAN1#104bis-e

·        FFS: reporting of desired beams for reception in DL or desired beams for transmission in UL by the IAB node for a given multiplexing mode

·        FFS: indicating applicable beams in DL or beams in UL for a given multiplexing mode.

8.10.33     Other

R1-2100221         Other enhancements for IAB           Huawei, HiSilicon

R1-2100465         Other enhancements to Rel-17 IAB nodes     vivo

R1-2100960         Discussion on multiplexing capability for IAB            ZTE, Sanechips

R1-2101085         Other enhancements to eIAB           ETRI

 RAN1#104-bis-e

8.10   Enhancements to Integrated Access and Backhaul

Please refer to RP-210758 for detailed scope of the WI

R1-2103984        Session notes for 8.10 (Enhancements to Integrated Access and Backhaul)   Ad-hoc Chair (Samsung)

R1-2103182         Workplan for Rel-17 IAB  Qualcomm Incorporated

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2102340         Resource multiplexing between backhaul and access for IAB duplexing enhancements      Huawei, HiSilicon

R1-2102538         Enhancement to resource multiplexing between child and parent links   vivo

R1-2103046         Enhancements to Resource Multiplexing between Child and Parent Links of an IAB Node      Intel Corporation

R1-2103120         Enhanced resource multiplexing within an IAB node Apple

R1-2103183         Resource management for enhanced duplexing           Qualcomm Incorporated

R1-2103255         Enhancements to Resource Multiplexing for NR IAB Samsung

R1-2103330         Discussion on IAB resource multiplexing enhancements          ETRI

R1-2103374         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

R1-2103435         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2103436         Enhancements for IAB resource multiplexing             AT&T

R1-2103497         Enhancements to the IAB resource multiplexing         ZTE, Sanechips

R1-2103591         Resource multiplexing between child and parent links of an IAB node   NTT DOCOMO, INC.

R1-2103608         Resource multiplexing in enhanced IAB systems        Lenovo, Motorola Mobility

R1-2103629         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2103712         Resource multiplexing and DC in enhanced IAB         Ericsson

R1-2103837        Summary of [104b-e-NR-eIAB-01] – Kickoff          Moderator (AT&T)

//Handled under NWM – See RAN1-104b-e-NWM-NR-eIAB-01 as the document name

[104b-e-NR-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node

-        1^st check point: April 15

-        2^nd check point: April 20

R1-2103838        Summary of [104b-e-NR-eIAB-01] – 1^st Checkpoint             Moderator (AT&T)

Agreement

The extension of the semi-static DU resource type indication to frequency-domain resources within a carrier (in addition to existing Rel-16 per-carrier granularity) for H/S/NA resource types is supported

Agreement

Adaptation of an IAB-node’s multiplexing operation is supported. The adaptation may be based on multiple factors, for example (not necessary to support all of the following):

·        Resource type (D/U/F) at the IAB-DU and IAB-MT

·        Specific sets of time/frequency resources

·        Certain conditions being met (e.g. supported timing modes, power control enhancements (if supported), etc.)

FFS: Mechanisms for informing/coordination the change in multiplexing operation(s) between child and parent nodes (including whether the adaptation is dynamic or semi-static)

FFS: Need for explicit linkage between indicated multiplexing operations and other features/enhancements – e.g. number of required guard symbols, supported timing modes, and power control enhancements (if supported)

Agreement

For the semi-static DU resource configuration in the frequency domain within a carrier, the frequency-domain granularity is configurable

• FFS:  minimum resource size e.g. N PRBs/N RBGs
• FFS: Separate or joint TDM and FDM semi-static DU resource configurations

Agreement

Soft resource availability indications for frequency-domain resources are supported

• FFS enhancements to DCI Format 2_5
• FFS: Separate or joint TDM and FDM indications

R1-2103839        Summary of [104b-e-NR-eIAB-01] – 2^nd Checkpoint            Moderator (AT&T)

R1-2103958        Summary of [104b-e-NR-eIAB-01] – Final Checkpoint        Moderator (AT&T)

Agreement

To facilitate simultaneous operations and interference management, dynamic indication for restriction/usage/availability of beams (in upstream and/or downstream directions) is supported

• FFS: Applicability to specific multiplexing cases or specific time-frequency resources
• FFS: Whether IAB-specific enhancements beyond the existing beam management framework are needed to the support the functionality
• FFS: Impact on the semi-static resource configurations (e.g., extending the H/S/NA resource attributes to the spatial domain)
• FFS: Whether panel-based granularity is additionally supported

Agreement

The following enhancements to support intra-band inter-carrier dual connectivity for both inter-donor and intra-donor scenarios are considered (in addition to reusing solutions for inter-band dual connectivity) to support simultaneous Tx and/or Rx at the child IAB-MT to/from both parent links:

• Extending the Rel-16 CA TDD conflict resolution framework for synchronous intra-band NR-DC operation
• Coordinating TDD configurations for the parent nodes (for both intra-donor and inter-donor operation) and coordinating H/S/NA configurations for the child node between donors (at least for inter-donor operation)

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed

Void (not be handled during this e-meeting). No contributions please.

The following is not treated/withdrawn.

R1-2103047         Other Enhancements for Simultaneous Operations     Intel Corporation

8.10.33     Other

Void (not be handled during this e-meeting). No contributions please.

 RAN1#105-e

8.10   Enhancements to Integrated Access and Backhaul

Please refer to RP-210758 for detailed scope of the WI

R1-2106234        Session notes for 8.10 (Enhancements to Integrated Access and Backhaul)   Ad-hoc Chair (Samsung)

R1-2104690         Workplan for Rel-17 IAB  Qualcomm Incorporated

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2104246         Resource multiplexing between backhaul and access for IAB duplexing enhancements      Huawei, HiSilicon

R1-2104382         Enhancement to resource multiplexing between child and parent links   vivo

R1-2104691         Resource management for enhanced duplexing           Qualcomm Incorporated

R1-2104877         Enhancements to the IAB resource multiplexing         ZTE, Sanechips

R1-2104924         Enhancements to Resource Multiplexing between Child and Parent Links of an IAB Node      Intel Corporation

R1-2105055         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

R1-2105124         Enhanced resource multiplexing within and across IAB nodes Apple

R1-2105226         Discussion on IAB resource multiplexing enhancements          ETRI

R1-2105331         Enhancements to Resource Multiplexing for NR IAB Samsung

R1-2105493         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2105617         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2105662         Enhancements for IAB resource multiplexing             AT&T

R1-2105716         Resource multiplexing between child and parent links of an IAB node   NTT DOCOMO, INC.

R1-2105763         Resource multiplexing in enhanced IAB systems        Lenovo, Motorola Mobility

R1-2105852         Resource multiplexing and DC in enhanced IAB         Ericsson

[105-e-NR-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node

·        1^st check point: May 24

·        2^nd check point: May 27

R1-2106054        Feature Lead Summary #1 of 8.10.1           Moderator (AT&T)

From GTW session:

Agreement

For frequency domain multiplexing, H/S/NA configurations for an IAB-node are provided separately in addition to the Rel-16 H/S/NA

Agreement

DCI Format 2_5 is reused to support soft resource availability indications for frequency-domain resources

·        FFS: If additional enhancements are necessary

R1-2106055        Feature Lead Summary #2 of 8.10.1           Moderator (AT&T)

Agreement

The parent IAB-node is dynamically provided with conditions/parameters to facilitate adaptation between multiplexing operation modes:

·        FFS: Required number of guard symbols for switching of multiplexing mode (FFS: per timing mode or per multiplexing mode) for IAB-DU

·        FFS: Signalling procedure

·        FFS: Required guard band for FDM

·        FFS: other conditions, e.g. required timing mode, required power control parameters, and preferred TCI.

Decision: As per email thread posted on May 25^th,

Agreement

If an IAB node is configured with a frequency-domain H/S/NA configuration down select between the following options:

• Alt. 1 Either the Rel-16 H/S/NA configuration or frequency domain configuration is applied for a given resource
• FFS: Whether configurations are switched with per-slot, per-resource type within a slot, or per-symbol granularity
• Alt. 2 The Rel-16 H/S/NA configuration and frequency domain configuration are jointly applied

Agreement

The minimum resource size for configuring the frequency domain granularity is a set of N RBs:

• Candidate values for N: {4, 8, 16, other values TBD}
• N is at least the # PRBs that are corresponding to the MT’s # PRBs of an RBG).
• FFS: Scaling or configuration of N based on system BW or size of IAB-MT BWP

Agreement

In case of intra-band inter-carrier dual connectivity for both inter-donor and intra-donor scenarios the following are supported:

• Reusing the Rel-16 CA TDD prioritization rules in case of UL/DL conflict when applicable
• FFS: Whether all prioritization rules apply in case of NR-DC
• FFS: Need of new prioritization rules in case of NR-DC
• Coordinating the IAB-MT’s TDD configurations to avoid conflicts from different parent nodes in case the child IAB-MT does not support simultaneous TX and RX on different carries
• FFS: Coordination for scheduling conflicts involving at least DCI Format 2_0 usage (e.g. usage of flexible symbols)
• Exchanging H/S/NA configurations between parent nodes/donors

R1-2106056        Feature Lead Summary #3 of 8.10.1           Moderator (AT&T)

From GTW session:

Agreement

In case of simultaneous MT/DU operation,

·        the parent node can dynamically indicate to the child node at least a set of restricted beams at the IAB-DU of the child node

·        the child node can dynamically report to the parent node a set of recommended beams, not preferred beams, or both recommended and not preferred beams of the IAB-MT of the child node

o   FFS: Whether the specification supports all reporting combinations.

·        FFS: Applicability to specific multiplexing cases or specific time-frequency resources

·        FFS: Additional semi-static signalling

·        FFS: Per-panel granularity in addition to per-beam granularity

·        FFS: Relationship between child IAB-MT beam indication and parent IAB-DU beam indication

·        Note: This does not preclude any enhancements for either DU or MT-based CLI measurement and reports

Agreement

For an IAB-MT with multiple serving cells (including the case with two parent nodes), a per-cell IAB-DU soft resource is considered as available if the resource is either explicitly indicated (via DCI 2_5), or implicitly determined as available with respect to all serving cells.

·        If the IAB-DU per-cell soft resource neither explicitly indicated as Available, nor implicitly determined as Available by the IAB-DU with respect to at least one serving cell

o   Alt 1. The IAB-DU per-cell resource is assumed to be not available

·        This agreement does not necessarily mean the Rel-16 spec does not support what is described in the main bullet

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed

R1-2104247         Enhancements for simultaneous operation of MT and DU         Huawei, HiSilicon

R1-2104383         Other enhancements for simultaneous operation of child and parent links             vivo

R1-2104692         Enhancements for simultaneous operation of IAB-node's child and parent links               Qualcomm Incorporated

R1-2104878         Enhancements for simultaneous operation of child and parent links        ZTE, Sanechips

R1-2104925         Other Enhancements for Simultaneous Operations     Intel Corporation

R1-2105065         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Fujitsu

R1-2105068         Discussion on simultaneous operation of IAB-node’s child and parent links               CEWiT

R1-2105125         Other enhancements for simultaneous operation of an IAB node's links Apple

R1-2105227         Discussion on simultaneous operation enhancements for eIAB ETRI

R1-2105332         Enhancements to Timing, Power Control and CLI for NR IAB Samsung

R1-2105494         Discussions on other enhancement for simultaneous operation LG Electronics

R1-2105618         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Nokia, Nokia Shanghai Bell

R1-2105663         Enhancements for IAB interference management        AT&T

R1-2105717         Other enhancements for simultaneous operation of IAB-node’s child and parent links               NTT DOCOMO, INC.

R1-2105764         Timing, interference, and power control in enhanced IAB systems         Lenovo, Motorola Mobility

R1-2105839         Timing, interference management and power control in enhanced IAB  Ericsson

//Handled under NWM – See RAN1-105-e-NWM-NR-eIAB-02 as the document name

[105-e-NR-eIAB-02] – Luca (Qualcomm)

Email discussion on other enhancements for simultaneous operation of IAB-node’s child and parent links

·        1^st check point: May 24

·        2^nd check point: May 27

R1-2106009        Feature lead summary#1 on enhancements for simultaneous operation of IAB-node’s child and parent links        Moderator (Qualcomm Inc.)

R1-2106083         Feature lead summary#2 on enhancements for simultaneous operation of IAB-node’s child and parent links        Moderator (Qualcomm Inc.)

R1-2106173        Feature lead summary#3 on enhancements for simultaneous operation of IAB-node’s child and parent links        Moderator (Qualcomm Inc.)

Agreement

Rel-16 CLI coordination signalling (Intended TDD DL-UL Configuration) is extended to support IAB specific UFD patterns.

• FFS: Support the exchange of IAB-DU H/S/NA resource configuration information among neighbouring IAB-nodes/IAB-donors for CLI management purposes.

Agreement

Decide in RAN1#106-e whether to support an IAB-node indicating assistance information to help with its MT’s UL TX power control. The assistance information can be:

·        FFS: Desired TX power

·        FFS: Offset to a baseline PHR

·        FFS: Desired dynamic range

FFS: whether this information is provided to the parent-node, the CU, or both.

FFS: whether the MT’s UL TX power control formula needs to be changed

Agreement

The information to assist DL power allocation of the parent-node is indicated by the IAB-MT to the parent node DU in terms of desired power adjustment.

·        FFS applicability of assistance information, e.g. per multiplexing scenario, per resource, etc.

R1-2106241        Feature lead summary#4 on enhancements for simultaneous operation of IAB-node’s child and parent links        Moderator (Qualcomm Inc.)

Agreement

RAN1 to downselect how the IAB-MT Tx timing is set for Case 6 timing at a given IAB-node:

·        Alt1: the IAB-MT Tx timing is obtained by the node via the legacy TA loop plus an offset from the parent node.

o   FFS details of the required offset.

·        Alt2: the IAB-MT Tx timing is set by the node to the timing obtained for the node’s DL Tx.

·        Alt3: the IAB-MT Tx timing is obtained by the node jointly with the IAB-DU Tx timing via a common offset from the parent node.

Downselection to consider at least the following aspects:

·        Dependency of DL synchronization schemes at the IAB-DU

·        Potential additional signaling overhead.

·        Achievable DU Tx / MT Tx alignment error tolerance.

·        Suitability for switching between timing modes.

Agreement

RAN1 to downselect how the IAB-MT Tx timing is set at an IAB-node for Case 7 timing at the parent node:

·        Alt1: the IAB-MT Tx timing of the node is obtained via the legacy TA loop plus an offset from the parent node.

o   FFS details of the required offset

·        Alt2: the IAB-MT Tx timing of the node is obtained via the legacy TA loop from the parent node.

·        Alt3: the IAB-MT Tx timing of the node is obtained via a Case 7 specific TA loop from the parent node.

Downselection to consider at least the following aspects:

·        Potential impact to OTA synchronization availability for DU Tx at the IAB-node.

·        Potential additional signaling overhead.

·        Suitability for switching between timing modes.

Agreement

An IAB-node is indicated when Case 6 timing is performed at the IAB-node.

·        FFS details of the indication (e.g. semi-static and/or dynamic, implicit and/or explicit, linkage to multiplexing capability, etc.).

FFS whether an IAB-node is also indicated when Case 7 timing is performed at the IAB-node.

Final summary in:

R1-2106313        Final feature lead summary on enhancements for simultaneous operation of IAB-node’s child and parent links              Moderator (Qualcomm Inc.)

8.10.33     Other

R1-2104384         Other enhancements to Rel-17 IAB nodes     vivo

R1-2104879         Consideration on reference carrier for semi-static IAB-DU resource configuration               ZTE, Sanechips

R1-2105525         Other enhancements for IAB           Huawei, HiSilicon

R1-2105840         Discussion on the payload size for DCI format 2_5    Ericsson

 RAN1#106-e

8.10   Enhancements to Integrated Access and Backhaul

Please refer to RP-211548 for detailed scope of the WI

R1-2107364         Workplan for Rel-17 IAB  Qualcomm Incorporated

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2106454         Resource multiplexing between backhaul and access for IAB duplexing enhancements      Huawei, HiSilicon

R1-2106617         Enhancement to resource multiplexing between child and parent links   vivo

R1-2106828         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2106907         Enhancements to Resource Multiplexing for NR IAB Samsung

R1-2107188         Resource multiplexing in enhanced IAB systems        Lenovo, Motorola Mobility

R1-2107365         Resource management for enhanced duplexing           Qualcomm Incorporated

R1-2107479         Discussion on IAB resource multiplexing enhancements          ETRI

R1-2107553         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2107607         Enhancements to resource multiplexing between child and parent links of an IAB node      Intel Corporation

R1-2107692         Enhancements for IAB resource multiplexing             AT&T

R1-2107758         Enhanced resource multiplexing within and across IAB nodes Apple

R1-2107824         Enhancements to the IAB resource multiplexing         ZTE, Sanechips

R1-2107877         Resource multiplexing between child and parent links of an IAB node   NTT DOCOMO, INC.

R1-2108107         Resource multiplexing and dual connectivity in enhanced IAB Ericsson

R1-2108161         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

[106-e-NR-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node

-        1^st check point: August 19

-        2^nd check point: August 25

-        3^rd check point: August 27

R1-2108277        Feature Lead Summary #1 of 8.10.1           Moderator (AT&T)

From GTW session:

Agreement

The following solutions are supported to handle potential indication conflict of overlapping flexible symbols between two parent IAB-nodes:

·        In intra-donor DC scenarios, if the IAB MT does not support simultaneous Tx and Rx on different carriers, it does not expect to receive conflicting DCI 2_0 from different parents.

Agreement

The IAB-donor-CU can be made aware of the IAB-MT’s capability regarding simultaneous transmission and reception on multiple serving cells in a frequency band, configured by the two parent nodes in intra-donor DC scenarios.

Agreement

The semi-static configuration of H/S/NA resource type in frequency domain is provided per RB set, per D/U/F resource type within a slot.

Agreement

N is a configured number of PRBs, where the CU configures N

·        N = {2, 4, 8, 16, 32, 64}

·        FFS: Value(s) of N in case of multiple configured BWPs at the IAB-MT

·        This agreement does not revert any existing RAN1 agreement

Agreement

For a given RB set at a symbol, if Rel-17 frequency domain H/S/NA configuration is not provided, the Rel-16 time domain H/S/NA is applied

Agreement

A Reference SCS is configured for frequency domain H/S/NA configuration.

Agreement

Spatial domain restrictions from a parent node or recommendations from a child node is limited to a subset of time resources in which simultaneous operation is applied.

·        FFS: Handling of frequency resources in case of FDM operation

·        FFS: Support for implicit/explicit indication of the simultaneous operation mode

Decision: As per email decision posted on Aug 24^th,

Agreement

The child node indication of recommended beams to the parent node can include both IAB-MT DL beams and/or IAB-MT UL beams.

·        FFS: Indication via MAC-CE or UCI transmission

·        FFS: Definition of IAB-MT DL beams and/or IAB-MT UL beams (e.g. TCI state ID, Spatial relation information ID, RS ID (including CSI-RS, SRS, SSB, etc.))

·        FFS: Whether indication of “not preferred” beams is supported

Agreement

MAC-CE signaling of Desired/Provided Guard Symbols is enhanced (e.g. using the same Rel-16 MAC-CE design) to support indication of guard symbols additionally required for Case #6 and Case #7 timing cases.

·        FFS: Number of guard symbols associated with Case #6 and Case #7 timing modes

·        FFS: Need for explicit indication of guard symbols switching between timing cases

Agreement

To support extension of CA TDD prioritization rules to NR-DC, the following resource coordination mechanisms between parents/donors are supported:

·        For intra-donor and inter-donor DC scenarios, in addition to coordination at the donor CU(s), a parent-node can be made aware of the DU resource configuration (UL/DL/FL, H/S/NA) of the other peer parent node that connects to the same IAB-node.

·        For intra-donor and inter-donor DC scenarios, coordinating the semi-static and/or cell-common higher layer configuration (e.g. SSB, CORESET 0, and RACH and configurations) from/for different parent nodes.

Decision: As per email decision posted on Aug 26^th,

Agreement

To support soft resource availability in the frequency domain, the existing DCI 2_5 format is reused according to one of the following alternatives:

·        Alt. 1: A single DCI format 2_5 can be received indicating availability for multiple RB sets which correspond to the same time resources of the child IAB-DU cell.

·        Alt. 2: Multiple DCI format 2_5 can be received indicating availability with the granularity of one or more RB set(s) for different RB sets which correspond to the same time resources of the child IAB-DU cell.

·        Alt. 3: A single DCI format 2_5 can be received indicating availability of all the soft resources which correspond to the same time resources of the child IAB-DU cell.

Decision: As per email decision posted on Aug 27^th,

Agreement

MAC-CE signaling from a parent node is supported for indication of beams of an IAB-DU in the direction of which simultaneous operation is restricted

• FFS: Details of beam indication (e.g. TCI state ID, Spatial relation information ID, RS ID (including CSI-RS, SRS, SSB, etc.))
• FFS: Applicability to other beams

Agreement

Select from the following alternatives to handle potential indication conflict of symbols configured as semi-static flexible by one parent node, but not the other in inter-donor DC scenarios if the IAB MT of the dual-connected IAB-node does not support simultaneous Tx and Rx on different carriers:

·        Alt. 1. The IAB MT does not expect to receive conflicting DCI formats including DCI2_0 and dynamic scheduling grants from different parents. FFS: Explicitly captured in the specification or left as a network configuration error case without specification impact

·        Alt. 6. The IAB-MT is expected to operate according to the non-flexible configuration.

Agreement

Select from the following alternatives to handle potential indication conflict of symbols configured as semi-static flexible by both parent nodes in inter-donor DC scenarios if the IAB MT of the dual-connected IAB-node does not support simultaneous Tx and Rx on different carriers:

·        Alt. 1: The IAB MT does not expect to receive conflicting DCI formats including DCI2_0 and dynamic scheduling grants from different parents. FFS: Explicitly captured in the specification or left as a network configuration error case without specification impact

·        Alt. 5: If a conflict occurs, the IAB MT is expected to perform as scheduled by MCG

·        FFS: Consideration of the impact of parent node’s H/S/NA when specifying the prioritization rules in case of UL/DL conflict

Conclusion

Decide in RAN1#106bis-e whether the parent IAB DUs of a DC connected IAB node can have per-backhaul-link resource configurations.

·        FFS: whether the per-backhaul-link configuration is provided to the dual-connected IAB node.

Final summary in:

R1-2108279        Feature Lead Summary #3 of 8.10.1           Moderator (AT&T)

//Handled under NWM – See RAN1-106-e-NWM-NR-eIAB-02 as the document name

[106-e-NR-eIAB-02] – Magnus (Ericsson)

Reply LS to R1-2106419 (LS on IAB resource multiplexing, RAN3) by August 20^th.

R1-2106419        LS on IAB resource multiplexing RAN3, Huawei

R1-2108494        Reply LS on IAB resource multiplexing    RAN1, Ericsson

Decision: As per email decision posted on Aug 24^th, the LS is approved.

//Handled under NWM – See RAN1-106-e-NWM-NR-eIAB-03 as the document name

[106-e-NR-eIAB-03] – Xinghua (Huawei)

Reply LS to R1-2106420 (LS on Inter-donor migration, RAN3) by August 20^th.

R1-2106420        LS on Inter-donor migration        RAN3, Samsung

R1-2108525        Draft reply LS on Inter-donor migration  Moderator (Huawei)

Decision: As per email decision posted on Aug 25^th, the draft LS is endorsed. Final LS is approved in R1-2108529.

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed

R1-2106455         Enhancements for simultaneous operation of MT and DU         Huawei, HiSilicon

R1-2106618         Other enhancements for simultaneous operation of child and parent links             vivo

R1-2106829         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Nokia, Nokia Shanghai Bell

R1-2106908         Enhancements to Timing, Power Control and CLI for NR IAB Samsung

R1-2107036         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Fujitsu

R1-2107189         Timing, interference, and power control in enhanced IAB systems         Lenovo, Motorola Mobility

R1-2107366         Enhancements for simultaneous operation of IAB-node's child and parent links               Qualcomm Incorporated

R1-2107480         Discussion on simultaneous operation enhancements for eIAB ETRI

R1-2107554         Discussions on other enhancement for simultaneous operation LG Electronics

R1-2107608         Other Enhancements for simultaneous operations       Intel Corporation

R1-2107693         Enhancements for IAB interference management        AT&T

R1-2107759         Other enhancements for simultaneous operation of an IAB node's links Apple

R1-2107825         Enhancements for simultaneous operation of child and parent links        ZTE, Sanechips

R1-2107878         Other enhancements for simultaneous operation of IAB-node’s child and parent links               NTT DOCOMO, INC.

R1-2108040         Discussion on simultaneous operation of IAB-node’s child and parent links               CEWiT

R1-2108108         Timing, interference management and power control in enhanced IAB  Ericsson

[106-e-NR-eIAB-04] – Luca (Qualcomm)

Email discussion on other enhancements for simultaneous operation of IAB-node’s child and parent links

-        1^st check point: August 19

-        2^nd check point: August 25

-        3^rd check point: August 27

R1-2108339        FL summary#1 on other enhancements for simultaneous operation of IAB-node’s child and parent links [106-e-NR-eIAB-04] Moderator (Qualcomm)

From GTW session:

Agreement

For Case 6 timing at a given IAB-node, the IAB-MT Tx timing is set by the node to the timing obtained for the node’s DL Tx.

·        FFS: Need for additional details with reference to support of OTA synchronization (e.g. T_delta)

Agreement

For Case 7 timing at a parent node, the IAB-MT Tx timing of the node is obtained via the legacy TA loop plus an offset from the parent node.

·        FFS range, granularity, and signaling details of the offset.

R1-2108479        FL summary#2 on other enhancements for simultaneous operation of IAB-node’s child and parent links [106-e-NR-eIAB-04] Moderator (Qualcomm)

From GTW session:

Agreement

For the support of DU-to-DU measurement and report:

·        For DU-to-DU CLI measurement:

o   Option 1.1. no specific mechanism is specified (e.g., it is handled by the implementation, or the available techniques)

·        For DU-to-DU CLI report:

o   Option 2.1. no specific mechanism is specified (e.g., it is handled by the implementation, or the available techniques)

Agreement

Support the exchange of semi-static Rel-16 IAB-DU H/S/NA resource configuration information and Rel-17 frequency domain IAB-DU H/S/NA resource configuration information among neighbouring IAB-nodes/IAB-donors

Decision: As per email decision posted on Aug 26^th,

Agreement

An IAB-node is explicitly indicated by the parent node when Case 6 timing is performed at the IAB-node at least for specific time resources.

·        FFS: whether the indication should be associated with another dimensions, e.g. multiplexing cases

·        FFS whether an IAB-node is explicitly indicated by the parent node when Case 7 timing is performed at the IAB-node.

Conclusion

Details on the design of the indication of when Case 6 timing (and Case 7 timing, if agreed) is performed at the IAB-node are to be discussed under 8.10.1.   

Agreement

An IAB-node is explicitly indicated by the parent node when Case 7 timing is performed at the parent node.

·        FFS for signalling details

Agreement

The desired DL TX power adjustment, indicated by the IAB-MT to its parent-node to assist with the parent-node’s DL TX power allocation, is provided at least for specific time resources. 

The desired DL TX power adjustment can further be associated with spatial configuration. (e.g., MT’s DL RX beams).

·        FFS: signalling details, e.g. indication via MAC-CE, PUCCH, or legacy CSI framework.

Agreement

Support an IAB-node indicating adjustment to its DL TX power to a child node (e.g., in response to receiving the DL TX power assistance information from the child node) at least for specific time resources.

The DL TX power adjustment indication can further be associated with spatial configuration. (e.g., MT’s DL RX beams).

·        FFS: signalling details.

Conclusion

Discuss under 8.10.1 whether CLI measurements should be included in the beam report from a node to its parent node.

Decision: As per email decision posted on Aug 29^th,

Agreement

Support an IAB-node indicating its desired IAB-MT PSD range to help with its MT’s UL TX power control.

-         This information is provided to the parent node

FFS: Applicability of assistance information, e.g., per multiplexing scenario, per resource, etc.

FFS: Signalling details, including the possibility to extend PHR.

Conclusion

In Rel-17 the following may be up to network implementation, no specific specification work required:

-         Differentiating access and backhaul slots.

-         Restricting simultaneous operation of MT and DU to DL slots.

Final summary in:

R1-2108568        FL summary#3 on other enhancements for simultaneous operation of IAB-node’s child and parent links [106-e-NR-eIAB-04] Moderator (Qualcomm)

8.10.33     Other

R1-2106619         Other enhancements to Rel-17 IAB nodes     vivo

R1-2106830         Discussion on inter-donor IAB migration and topology redundancy       Nokia, Nokia Shanghai Bell

R1-2107665         Other enhancements for IAB           Huawei, HiSilicon

R1-2107826         Consideration on reference carrier for semi-static IAB-DU resource configuration               ZTE, Sanechips

R1-2108109         Discussion on overlapping DCI format 2_5 indications in enhanced IAB               Ericsson

 RAN1#106-bis-e

8.10   Enhancements to Integrated Access and Backhaul

Please refer to RP-211548 for detailed scope of the WI.

Incoming LS(s) related to this work/study item under agenda item 5: R1-2108719, R1-2109373.

[106bis-e-R17-RRC-eIAB] – Luca (Qualcomm)

Email discussion on Rel-17 RRC parameters for eIAB

-        1^st check point: October 14

-        Final check point: October 19

R1-2110701        Summary of [106bis-e-R17-RRC-eIAB] Email discussion on Rel-17 RRC parameters for eIAB       Moderator (Qualcomm)

Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].

R1-2110692         RAN1 decisions for Rel-17 eIAB    WI rapporteur (Qualcomm)

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2108765         Resource multiplexing between backhaul and access for IAB duplexing enhancements      Huawei, HiSilicon

R1-2108826         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2108995         Enhancement to resource multiplexing between child and parent links   vivo

R1-2109261         Enhancements to the IAB resource multiplexing         ZTE, Sanechips

R1-2109510         Enhancements to Resource Multiplexing for NR IAB Samsung

R1-2109629         Enhancements to Resource Multiplexing between Child and Parent Links of an IAB Node      Intel Corporation

R1-2109697         Resource multiplexing between child and parent links of an IAB node   NTT DOCOMO, INC.

R1-2109816         Discussion on IAB resource multiplexing enhancements          ETRI

R1-2109839         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

R1-2109920         Enhancements for IAB resource multiplexing             AT&T

R1-2109936         Resource multiplexing in enhanced IAB systems        Lenovo, Motorola Mobility

R1-2110051         Enhanced resource multiplexing within and across IAB nodes Apple

R1-2110101         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2110206         Resource management for enhanced duplexing           Qualcomm Incorporated

R1-2110331         Resource multiplexing and dual connectivity in enhanced IAB Ericsson

[106bis-e-NR-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node

-        1^st check point: October 14

-        Final check point: October 19

R1-2110442        Feature lead summary #1 of 8.10.1             Moderator (AT&T)

From Oct 11^th GTW session

Agreement

Select the following alternative to handle potential indication conflict of symbols configured as semi-static flexible by one parent node, but not the other in inter-donor DC scenarios if the IAB MT of the dual-connected IAB-node does not support simultaneous Tx and Rx on different carriers:

·        Alt. 1. The IAB MT does not expect to receive conflicting DCI formats including DCI2_0 and dynamic scheduling grants from different parents. FFS: Explicitly captured in the specification or left as a network configuration error case without specification impact

Select the following alternative to handle potential indication conflict of symbols configured as semi-static flexible by both parent nodes in inter-donor DC scenarios if the IAB MT of the dual-connected IAB-node does not support simultaneous Tx and Rx on different carriers:

·        Alt. 5: If a conflict occurs, the IAB MT is expected to perform as scheduled by MCG

Agreement:

In DC scenarios, support per-child MT link-NA resource configuration.

·        This configuration can be made available to IAB node as well

R1-2110443        Feature lead summary #2 of 8.10.1             Moderator (AT&T)

From Oct 15^th GTW session

Agreement

The Rel-17 frequency domain H/S/NA configuration is provided across multiple slots and/or over a subset of slots only, with the same time-domain granularity and pattern duration as the Rel-16 H/S/NA configuration (i.e. gNB-DU Cell Resource Configuration (9.3.1.107 in TS 38.473 [8])).

·        For a given slot, different H/S/NA resource types can be configured for different RB sets

·        Additional signaling details (e.g. bitmap, slot pattern, etc.) can be left up to RAN3

·        FFS: The number of different frequency domain configurations at a given time

Agreement

A single value for the RB set size, N, is configured for a given IAB-DU cell’s Rel-17 frequency domain H/S/NA configuration.

Working Assumption

If both the Rel-16 time domain H/S/NA configuration and Rel-17 frequency domain H/S/NA configuration are provided for a given RB set within a slot, one of the following is selected:

·        Alt. 1: An IAB node applies the frequency domain H/S/NA only if the IAB node is currently operating in a non-TDM multiplexing mode in the slot, otherwise the Rel-16 time domain H/S/NA configuration is applied.

For RAN1#107-e, companies to consider the following decision point:

An IAB node (or parent node) cannot operate under a given non-TDM multiplexing mode until:

·        Alt. 1: All required conditions and parameters which have been directly indicated/requested to the parent node (e.g. via MAC-CE) are explicitly acknowledged by the parent node.

·        Alt. 2: All required conditions and parameters which have been directly indicated/requested to the parent node (e.g. via MAC-CE) are implicitly acknowledged by the parent node or implicitly determined at the child node

Decision: As per email posted on Oct 18^th,

Agreement

RS ID, based on the IAB node’s DU configurations, is used by a parent node to indicate beams of an IAB-DU in the direction of which simultaneous operation is restricted

·        At least SSB ID and [STC index] are supported

·        FFS: Whether restrictions are indicated to apply differently for H or S resources

·        FFS: Informing the parent node of SRS configuration of the IAB-MT (if collocated with the IAB-DU)

Agreement

The restricted beam indication from the parent node to the IAB node may be indicated (or specified) to be associated with some combination (one or multiple) of the following IAB node’s parameters:

·        [Multiplexing mode]

·        [MT’s DL beam (e.g. TCI state id)] or MT’s UL beam (e.g., SRI id)

·        [DU resource configuration (e.g. soft resources)]

·        [Slot index]

Agreement

The MAC-CE signaling of Desired/Provided Guard Symbols is enhanced to optionally indicate the number of guard symbols required for switching between at least the following cases:

·        Case#6 MT Tx and [Case #7] DU [Tx]/Rx

·        Case#7 MT Tx (to support Case #7 at parent node) and DU Tx/Rx

Decision: As per email posted on Oct 19^th,

Agreement

The recommended beam indication from the IAB-MT to the parent node are provided via MAC-CE:

·        For DL Rx beam(s): using one or more of the following:

o   DL TCI state ID

§  FFS: UE/IAB-MT does not assume that DL Tx power adjustment (if provided) is applied to the SSB index (if supported) indicated as QCLed reference signal in DL TCI state ID. 

o   [RS ID]

o   [R17 DL TCI, or joint DL/UL TCI ID]

·        For UL Tx beam(s): using one or more of the following:

o   [Spatial relation]

o   [RS ID]

o   [R17 UL TCI, or joint DL/UL TCI ID]

o   [SRI]

Agreement

A single DCI format 2_5 can be received indicating availability for the soft resources of the respective RB sets corresponding to a given time resource of the child IAB-DU cell.

• FFS: Extension of AvailabiltyCombination to include multiple RB sets in a resourceAvailabilty indication
• FFS: Update resourceAvailability mapping table defined in TS38.213 so that the indication of availability can be applied over soft resources in frequency-domain for DL or UL or Flexible symbols.
• FFS: Need for extension of the maximum payload size of DCI format 2_5 to increase the number of IAB-DU cells that can be provided with availability information for Soft resources to accommodate the maximum number of possible RB sets for a given DU cell (if defined), or other backwards compatible signaling extensions in case the principal indication capabilities of DCI format 2_5 are increased.

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed.

R1-2108766         Enhancements for simultaneous operation of MT and DU         Huawei, HiSilicon

R1-2108827         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Nokia, Nokia Shanghai Bell

R1-2108996         Other enhancements for simultaneous operation of child and parent links             vivo

R1-2109262         Enhancements for simultaneous operation of child and parent links        ZTE, Sanechips

R1-2109511         Enhancements to Timing, Power Control and CLI for NR IAB Samsung

R1-2109630         Other Enhancements for Simultaneous Operations     Intel Corporation

R1-2109698         Other enhancements for simultaneous operation of IAB-node’s child and parent links               NTT DOCOMO, INC.

R1-2109817         Discussion on simultaneous operation enhancements for eIAB ETRI

R1-2109840         Discussion on simultaneous operation of IAB-node’s child and parent links               CEWiT

R1-2109921         Enhancements for IAB interference management        AT&T

R1-2109937         Timing, interference, and power control in enhanced IAB systems         Lenovo, Motorola Mobility

R1-2110052         Other enhancements for simultaneous operation of an IAB node's links Apple

R1-2110102         Discussions on other enhancement for simultaneous operation LG Electronics

R1-2110207         Enhancements for simultaneous operation of IAB-node's child and parent links               Qualcomm Incorporated

R1-2110332         Timing, interference management and power control in enhanced IAB  Ericsson

[106bis-e-NR-eIAB-02] – Luca (Qualcomm)

Email discussion on other enhancements for simultaneous operation of IAB-node’s child and parent links

-        1^st check point: October 14

-        Final check point: October 19

R1-2110497        Summary#1 [106bis-e-NR-eIAB-02] on other enhancements for simultaneous operation of IAB-node’s child and parent links      Moderator (Qualcomm Incorporated)

From Oct 13^th GTW session

Agreement

The following alternative is selected for the association between the indicated parent-node’s DL TX power adjustment, provided by an IAB-MT to its parent-node, and IAB-node’s resources and/or configurations:

·        Alt 2. The desired DL TX power adjustment is indicated to be associated with some combination (one or multiple) of the following IAB-node’s configurations:

o   Multiplexing mode

o   MT’s DL beam (e.g. TCI state id)

o   (MT CC, DU cell) pair

o   DU resource configuration

o   FFS: Slot index

o   FFS: timing mode (e.g., Case-7 timing)

Decision: As per email posted on Oct 19^th,

Agreement

Case 7 UL timing offset is indicated by the parent-node via MAC-CE.

Agreement

The granularity of Case 7 UL timing offset is the same as the UL TA granularity.

Conclusion

RAN1 does not discuss further proposals for IAB interference management enhancements in 8.10.2.

Decision: As per email posted on Oct 20^th,

Agreement

The desired parent-node’s DL TX power adjustment, provided by an IAB-MT to its parent-node, is indicated via MAC-CE.

• The indication further includes the associated configurations and/or resources for which the indicated power adjustment is applicable.
• The indicated adjustment is in terms of a relative offset to a reference DL TX power.

o   FFS: the reference power (e.g., an RS such as CSI-RS, etc) for the indication of desired adjustment.

o   FFS: the range of values for the indicated adjustment.

Agreement

The desired IAB-MT’s UL PSD range, provided by the IAB-MT to its parent-node, is indicated to be associated with some combination (one or multiple) of the following IAB-node’s configurations:

• Multiplexing mode,
• MT’s UL beam (e.g., SRI id),
• (MT CC, DU cell) pair,
• DU resource configuration
• FFS: slot index
• FFS: timing mode (e.g., Case-6 timing)

Agreement

The desired IAB-MT’s UL PSD range, provided by an IAB-MT to its parent-node, is indicated via a new MAC-CE.

• The indication further includes the associated configurations for which the indicated PSD range is applicable.
• FFS: the range of values for the indicated PSD range and whether RAN4 input is needed.
• FFS: IAB-MT’s behaviour in case the configured/indicated UL TX power is outside the indicated desired PSD range and whether RAN4 input is needed.

Conclusion

RAN1 to further discuss, under 8.10.2, whether to support new triggering conditions to send an updated PHR (e.g., upon change of multiplexing mode, or applying a desired DL TX power adjustment indication from a child-node).

Agreement

The DL TX power adjustment, provided by the parent-node to IAB-MT, is indicated to be associated with some combination (one or multiple) of the following IAB-node’s configurations:

• Multiplexing mode
• MT’s DL beam (e.g., TCI state id, RS id)
• (MT CC, DU cell) pair
• DU resource configuration
• FFS: DL signal/channel type
• FFS: slot index
• FFS: timing mode (e.g., Case-7 timing)

Agreement

The DL TX power adjustment, provided by the parent-node to the IAB-MT, is indicated via MAC-CE.

• The indication further includes the associated configurations and/or resources for which the indicated power adjustment is applicable.
• The indicated adjustment is in terms of a relative offset to a reference DL TX power.

o   FFS: the reference power (e.g., an RS such as CSI-RS, etc) for the indication of DL Tx power adjustment.

o   FFS: the range of values for the indicated adjustment.

Agreement

The indicated DL TX power adjustment is not applied to SSBs.

• FFS: any other cell-specific/semi-static DL signal to be exempted.
• FFS: applicability of the indicated TX power adjustment to other RS/channel which share the same QCL Type-D assumption.

Agreement

RAN1 to down select in RAN1#107-e one of the following for an OTA timing synchronization mechanism to enable/maintain Case 6 timing mode:

• Alt 1: no change or enhancement to the Rel-16 OTA synchronization specification is supported in Rel-17 for Case 6 timing.
• Alt 2: in Rel-17 the Rel-16 OTA synchronization specification is updated to support OTA synchronization for an IAB-node operating solely in Case 6 timing during IAB-MT Tx.
• FFS range of T_delta.

NOTE: this is to provide a feasible solution to the RAN1#103-e agreement: “An IAB-node can rely on an OTA timing synchronization mechanism to enable/maintain Case 6 timing mode”

Final summary in R1-2110515.

8.10.33     Other

R1-2108997         Other enhancements to Rel-17 IAB nodes     vivo

R1-2109263         Consideration on reference carrier for semi-static IAB-DU resource configuration               ZTE, Sanechips

R1-2109755         Other enhancements for IAB           Huawei, HiSilicon

R1-2110333         On RRC parameters in enhanced IAB            Ericsson

 RAN1#107-e

8.10   Enhancements to Integrated Access and Backhaul

Please refer to RP-211548 for detailed scope of the WI.

Rel-17 CRs related to IAB

R1-2112442        Introduction of R17 eIAB              Samsung

Decision: Draft CR to 38.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.

[107-e-R17-RRC-eIAB] – Luca (Qualcomm)

Email discussion on Rel-17 RRC parameters for eIAB

-        Email discussion to start on November 15

R1-2112966        Summary of [107-e-R17-RRC-eIAB] on Rel-17 higher layer parameters (RRC, MAC-CE, and F1AP) for eIAB     Moderator (Qualcomm) (rev of R1-2112838)

Document is noted. For consolidation under 8 in [107-e-R17-RRC].

R1-2112965         RAN1 decisions for Rel-17 eIAB    WI rapporteur (Qualcomm)

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2110775         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2110834         Resource multiplexing between backhaul and access for IAB duplexing enhancements      Huawei, HiSilicon

R1-2111033         Remaining issues on enhancement to resource multiplexing between child and parent links      vivo

R1-2111512         Enhancements to Resource Multiplexing between Child and Parent Links of an IAB Node      Intel Corporation

R1-2111591         Enhancements to the IAB resource multiplexing         ZTE, Sanechips

R1-2111756         Enhancements to Resource Multiplexing for NR IAB Samsung

R1-2111804         Enhancements for IAB resource multiplexing             AT&T

R1-2111892         Enhanced resource multiplexing within and across IAB nodes Apple

R1-2111952         Resource multiplexing in enhanced IAB systems        Lenovo, Motorola Mobility

R1-2111983         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2111995         Discussion on IAB resource multiplexing enhancements          ETRI

R1-2112124         Resource multiplexing between child and parent links of an IAB node   NTT DOCOMO, INC.

R1-2112183         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

R1-2112235         Resource management for enhanced duplexing           Qualcomm Incorporated

R1-2112356         Resource multiplexing in enhanced IAB        Ericsson

[107-e-NR-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node

-        1^st check point: November 15

-        Final check point: November 19

R1-2112602        Feature lead summary #1 of 8.10.1             Moderator (AT&T)

From Nov 12^th GTW session

Agreement:

Support indication of whether FDM is required or not for an enhanced multiplexing operation mode to donor-CU.

Agreement:

An IAB-MT is provided with a Timing Case Indication via MAC-CE that explicitly indicates a list of slots and their associated UL TX timing cases (i.e., one of {Case 1, Case 6, Case 7} for each slot).

Agreement:

The maximum number of non-overlapping RB sets configurable per DU cell is M

·        where, M is to be selected from one of values from 4, 8, 16

·        DU frequency configuration information should be provided to the parent node.

Agreement:

Whether or not an IAB node can operate under a given non-TDM multiplexing mode (i.e. multiplexing info in 38.473) is left to IAB implementation in Rel-17

Decision: As per email decision posted on Nov 17^th,

Agreement:

In addition to SSB ID, CSI-RS ID may be additionally used as the RS ID for a restricted beam indication from the parent node to the IAB node.

·        STC index may be additionally indicated along with SSB ID if more than one STC is configured at the IAB node.

·        Note: This does not mean that IAB-specific CSI-RS should be developed and requires no additional specification work

Agreement:

·        The maximum number of recommended beams per MT CC in a given indication (including all associated parameters/conditions) is 8.

·        The maximum number of restricted beams per DU cell in a given indication (including all associated parameters/conditions) is 8.

Decision: As per email decision posted on Nov 19^th,

Agreement

The recommended beam indication from the IAB-MT to the parent node are provided using the following:

·        For DL Rx beam(s) 

o   DL TCI state ID and RS ID (SSB ID and/or CSI-RS ID)

·        For UL Tx beam(s) 

o   SRI

Agreement

A child IAB-MT can inform a parent node via MAC-CE whether Case 6 timing is required for simultaneous operation.

Agreement

A Timing Case Indication received from a serving cell is applicable to all other cells in the same timing advance group (TAG).

R1-2112603        Feature lead summary #2 of 8.10.1             Moderator (AT&T)

From Nov 19^th GTW session

Agreement

For DCI format 2_5 indicating availability for the soft resources of the respective RB sets corresponding to a given time resource of the child IAB-DU cell:

·        AvailabiltyCombination can be extended to include multiple resourceAvailabilty, where each resourceAvailabilty includes availability indication for one RB set group

o   One RB set group consists of one or multiple RB sets

Agreement

The following RAN1#106bis-e agreement is updated.

The MAC-CE signaling of Desired/Provided Guard Symbols is enhanced to optionally indicate the number of guard symbols required for switching between at least the following cases:

·        Case#6 MT Tx and [Case #7] DU [Tx]/Rx

·        Case#7 MT Tx (to support Case #7 at parent node) and DU Tx/Rx

·        A: Case #6 MT TX to/from Case #1 DU RX

·        D: Case #7 MT TX (to support Case #7 at parent node) to/from Case #1 DU RX

·        G: Case #7 MT TX (to support Case #7 at parent node) to/from Case #1 DU TX

·        (Working Assumption) H: Case #6 MT TX to/from Case #1 DU TX

Decision: As per email decision posted on Nov 20^th,

Agreement

The value of the maximum number of contiguous and non-overlapping RB sets configurable per DU cell, M is 8.

Agreement

The IAB-DU is expected to apply the indicated beam restriction within its soft resources that are not explicitly indicated as available.

Agreement

The restricted beam indication from the parent node to the IAB node may be indicated to be associated with some combination (one or multiple) of the following IAB-node’s configurations:

·        {MT CC, DU cell} pair and optionally may be indicated to be associated with only {DU cell} if independent of MT CC(s)

·        Multiplexing mode info (i.e. multiplexing info in 38.473) and optionally may be indicated to be applicable to non-overlapping frequency resources

·        Slot index

·        Association with IAB-MT’s DL Rx beam via TCI state ID and RS ID (SSB ID and/or CSI-RS ID) or UL TX beam via SRI

Agreement

The recommended beam indication from the IAB node to the parent node may be indicated to be associated with some combination (one or multiple) of the following IAB-node’s configurations:

·        {MT CC, DU cell} pair and optionally may be indicated to be associated with only {MT CC} if independent of DU cell(s)

·        Multiplexing mode info (i.e. multiplexing info in 38.473) and optionally may be indicated to be applicable to non-overlapping frequency resources

·        Slot index

Final summary in R1-2112804.

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed.

R1-2110776         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Nokia, Nokia Shanghai Bell

R1-2110835         Enhancements for simultaneous operation of MT and DU         Huawei, HiSilicon

R1-2111034         Remaining issues on enhancements for simultaneous operation of child and parent links      vivo

R1-2111513         Support for Case#6 and Case#7 Timing Alignment    Intel Corporation

R1-2111592         Enhancements for simultaneous operation of child and parent links        ZTE, Sanechips

R1-2111757         Enhancements to Timing, Power Control and CLI for NR IAB Samsung

R1-2111805         Enhancements for IAB interference management        AT&T

R1-2111893         Other enhancements for simultaneous operation of an IAB node's links Apple

R1-2111953         Timing, interference, and power control in enhanced IAB systems         Lenovo, Motorola Mobility

R1-2111984         Discussions on other enhancement for simultaneous operation LG Electronics

R1-2111996         Discussion on simultaneous operation enhancements for eIAB ETRI

R1-2112125         Other enhancements for simultaneous operation of IAB-node’s child and parent links               NTT DOCOMO, INC.

R1-2112236         Enhancements for simultaneous operation of IAB-node's child and parent links               Qualcomm Incorporated

R1-2112267         Discussion on simultaneous operation of IAB-node’s child and parent links               CEWiT

R1-2112357         Timing and power control in enhanced IAB  Ericsson

[107-e-NR-eIAB-02] – Luca (Qualcomm)

Email discussion on other enhancements for simultaneous operation of IAB-node’s child and parent links

-        1^st check point: November 15

-        Final check point: November 19

Decision: As per email decision posted on Nov 16^th,

Agreement

The dynamic range of the MAC CE case #7 timing offset indication is 12 bits.

·        FFS the numerical values of the endpoints of the range

Conclusion

In Rel-17 there is no specification support for the indication of “timing mode” in the desired/provided DL TX power adjustment or the desired UL PSD range indication.

·        Note: This does not prevent the indication of case 6 timing mode and UL PSD range as separate conditions to enable a given multiplexing case.

Conclusion

In Rel-17 there is no specification support for the indication of “DL signal/channel type” in the provided DL TX power adjustment indication.

Agreement

Send an LS to RAN4 to specify the range of values for the indication of the desired/provided DL TX power adjustment, as well as the range of values for the indication of the desired MT UL PSD range.

From post-meeting

R1-2112972        [DRAFT] LS on range of power control parameters for eIAB           Moderator (Qualcomm)

Decision: As per email decision posted on Dec 1^st, the draft LS is endorsed. Final LS is approved in R1-2112973.

Agreement

The provided DL TX power adjustment is applied only to PDSCH and its associated DMRS and PTRS.

Agreement

The indicated desired/provided DL TX power adjustment is in terms of a relative offset to the PDSCH a CSI-RS TX power that is RRC configured.

Conclusion

For Rel-17, no further discussion in RAN1 on eIAB supporting new triggering conditions for sending an updated PHR.

R1-2112636        Summary#1 for [107-e-NR-eIAB-02] on other enhancements for simultaneous operation of IAB-node's child and parent links      Moderator (Qualcomm)

From Nov 16^th GTW session

Agreement

Select Alt 2 from the aforementioned RAN1#106b-e agreement without specification impact other than the following:

·        Alt A: the T_delta range is updated to support Case 6 timing.

FFS: Update of one way delay estimation equation in TS38.213 subclause 14

Agreement

TCI state ID and RS ID (SSB ID and/or CSI-RS ID) is used to indicate IAB-MT’s DL beam for the desired/provided DL TX power adjustment indication by the IAB-node/the parent-node.

In case the desired/provided DL TX power adjustment indication does not include information about the associated IAB-MT’s DL beams, the adjustment is applied to all MT’s DL beams.

Agreement

SRI is used to indicate IAB-MT’s UL beam for the desired UL PSD range indication.

In case the desired UL PSD range indication does not include information about the associated IAB-MT’s UL beams, the PSD range is applied to all MT’s UL beams.

Agreement

Support optionally indicating “slot index” in the provided DL TX power adjustment indication, that comprises indicating a list of one or multiple slot indices for which the associated DL power adjustment is applied.

·        FFS:  support of “slot index” indication in the desired DL TX power adjustment

·        FFS:  support of “slot index” indication in the desired UL PSD range indication

Decision: As per email decision posted on Nov 20^th,

Agreement

The indication of the desired/provided DL TX power adjustment and desired UL PSD range can further include:

·        An indication of whether a desired/provided power configuration or adjustment is applied on FDM resources where the simultaneous MT’s and DU’s signals are non-overlapping in the frequency-domain and/or on non-FDM resources where the simultaneous MT’s and DU’s signals may overlap in the frequency-domain, for a given (MT CC, DU cell).

Agreement

Support optionally indicating “slot index” in the provided DL TX power adjustment indication, that comprises indicating a list of one or multiple slot indices for which the associated DL power adjustment is applied.

·        Support of “slot index” indication in the desired DL TX power adjustment indication

Final summary in R1-2112837.

8.10.33     Other

R1-2111035         Other enhancements to Rel-17 IAB nodes     vivo

R1-2111593         Consideration on reference carrier for semi-static IAB-DU resource configuration               ZTE, Sanechips

R1-2111929         Other enhancements for IAB           Huawei, HiSilicon

R1-2112358         Prioritization of remaining work in eIAB      Ericsson

 RAN1#107-bis-e

8.100   Maintenance on Enhancements to Integrated Access and Backhaul

Void (not be handled during this e-meeting).

 RAN1#108-e

8.10   Maintenance on Enhancements to Integrated Access and Backhaul

[108-e-R17-RRC-eIAB] – Luca (Qualcomm)

Email discussion on Rel-17 higher layer parameters (RRC, MAC-CE, and F1AP) for eIAB

-        1^st check point for first LS in [108-e-R17-RRC]: February 24

-        Final check point for second LS in [108-e-R17-RRC] if necessary: March 3

R1-2202907        Summary of [108-e-R17-RRC-eIAB] Email discussion on Rel-17 RRC parameters for eIAB       Moderator (Qualcomm)

Document is noted. For consolidation under 8 in [108-e-R17-RRC].

R1-2202943         RAN1 decisions for Rel-17 eIAB    WI rapporteur (Qualcomm)

[108-e-R17-eIAB-03] – Luca (Qualcomm)

Email discussion on Rel-17 MAC-CE and F1AP for eIAB by February 25

R1-2202726        [Draft] LS on upper layers parameters for Rel-17 eIAB      Qualcomm

Decision: As per email decision posted on Mar 1^st, the draft LS on upper layers parameters for Rel-17 eIAB to RAN2, RAN3 is endorsed. Final LS is approved in R1-2202737.

By the end of the meeting, an updated list of parameters based on all the agreements made in RAN1#108-e is endorsed.

R1-2202947        LS on upper layers parameters for Rel-17 eIAB     RAN1, Qualcomm

Decision: As per email decision posted on Mar 3^rd, the LS on updated upper layers parameters for Rel-17 eIAB is approved. That LS supersedes the previous one in x2737.

R1-2202155        Text proposals for RAN1 related IAB updates to TS 38.300 Qualcomm Incorporated

[108-e-R17-eIAB-04] – Luca (Qualcomm)

Email discussion on eIAB TP (R1-2202155) for 38.300 by February 24

Decision: As per email decision posted on Feb 26^th,

Agreement

The following TPs are endorsed from RAN1 perspective for TS38.300.

Note: A paragraph on FDM H/S/NA resource configuration will be added after the associated behavior is agreed under AI 8.10.1.

LS to RAN2 in

R1-2202884        LS on IAB related RAN1  TP for TS 38.300            RAN1, Qualcomm

Decision: As per email decision posted on Mar 3^rd, the LS is approved.

8.10.1     Enhancements to resource multiplexing between child and parent links of an IAB node

R1-2200926         Remaining issues on resource multiplexing between backhaul and access               Huawei, HiSilicon

R1-2201109         Remaining issues on enhancement to resource multiplexing between child and parent links      vivo

R1-2201456         Enhancements to the IAB resource multiplexing         ZTE, Sanechips

R1-2201492         Remaining issues on resource multiplexing  NTT DOCOMO, INC.

R1-2201526         Enhancements to Resource Multiplexing for NR IAB Samsung

R1-2201614         Discussion on IAB resource multiplexing maintenance             ETRI

R1-2201673         Enhancements for resource multiplexing among IAB backhaul and access links               Nokia, Nokia Shanghai Bell

R1-2201713         Frequency-domain Resource Multiplexing for IAB     Intel Corporation

R1-2202090         Resource multiplexing in enhanced IAB systems        Lenovo

R1-2202156         Remaining issues on resource management for enhanced duplexing       Qualcomm Incorporated

R1-2202305         Discussions on IAB resource multiplexing enhancements         LG Electronics

R1-2202402         Resource multiplexing and dual connectivity in enhanced IAB Ericsson

[108-e-R17-eIAB-01] – Thomas (AT&T)

Email discussion on enhancements to resource multiplexing between child and parent links of an IAB node

-        1^st check point: February 25

-        Final check point: March 3

R1-2202547        Feature lead summary #1 of 8.10.1             Moderator (AT&T)

From Feb 21^st GTW session

Agreement

The working assumption in the RAN1#107-e agreement is confirmed

The MAC-CE signaling of Desired/Provided Guard Symbols is enhanced to optionally indicate the number of guard symbols required for switching between at least the following cases:

·        A: Case #6 MT TX to/from Case #1 DU RX

·        D: Case #7 MT TX (to support Case #7 at parent node) to/from Case #1 DU RX

·        G: Case #7 MT TX (to support Case #7 at parent node) to/from Case #1 DU TX

(Working Assumption) H: Case #6 MT TX to/from Case #1 DU TX

Decision: The working assumption is confirmed on Feb 25^th GTW session.

Agreement

The number of desired/provided guard symbols indicated for Rel-17 cases should be in the range of 0-7 symbols.

Agreement

The list of slots associated with a given timing cases provided to an IAB-MT by the Timing Case Indication MAC CE has the same range and periodicity as the list of slots IAB DU resource configuration

·        FFS (to be revisited via email on Feb 23): As in Rel-17 HSNA configuration

·        This agreement extends to other eIAB MAC CEs (e.g. restricted/recommended beam indications)

Decision: As per email decision posted on Feb 24^th,

Agreement

In order to support the agreed extension of CA TDD conflict resolution rules to IAB nodes operating under NR-DC in Rel-17 (covering both inter-donor and intra-donor NR-DC scenarios)

·        Introduce new RRC parameter: directionalCollisionHandling-r17

·        Update parameter description for half-duplexTDD-CA-SameSCS-r16 in TS38.306 to make it clear that it is applicable for NR-DC for IAB-MT. E.g. “if this field is included in ca-ParametersNR-forDC-v1610 for IAB-MT, it indicates IAB-MT supports directional collision handling between reference and other cells for half-duplex operation in TDD NR-DC with same SCS across MCG and SCG”

Agreement

Update Rel-17 TS 38.213 Section 14 in the following manner:

·        If an IAB MT is configured with an MCG and an SCG, is not capable of simultaneous transmission and reception, and would simultaneously transmit and receive on the MCG and the SCG, the IAB- MT operates according to the scheduling from the MCG only if semi-static flexible symbols are configured by both parents operating under inter-donor NR-DC.

·        For other NR-DC cases, the IAB-MT shall apply the Rel-16 CA TDD prioritization rules defined in TS38.213 section 11.1 across cell groups (i.e. The IAB MT does not expect to receive conflicting DCI formats including DCI2_0 and dynamic scheduling grants from different parents).

Agreement

·        The list of slots associated with a given timing cases provided to an IAB-MT by the Timing Case Indication MAC CE (P15 in [108-e-R17-eIAB-03]) can have the following ranges for periodicity: {16, 20, 32, 40, 64, 80, 160, 320, 640, 1280, 2560, 5120} slots

·        This agreement extends to other eIAB MAC CEs including:

o   Child IAB-DU Restricted Beam Indication MAC CE (P12 in [108-e-R17-eIAB-03])

o   Desired DL TX Power Adjustment MAC CE (P17 in [108-e-R17-eIAB-03])

o   DL TX Power Adjustment MAC CE (P18 in [108-e-R17-eIAB-03])

o   Desired IAB-MT PSD range MAC CE (P19 in [108-e-R17-eIAB-03])

o   IAB-MT Recommended Beam Indication MAC CE (P23 in [108-e-R17-eIAB-03])

R1-2202702        Feature Lead Summary #2 of 8.10.1           Moderator (AT&T)

From Feb 25^th GTW session

Agreement

The following IAB-DU behavior is defined in case of multiple indicated beam restrictions or recommendations with different configurations across indications:

·        Alt1: Each MAC CE indication provides complete information on beam restriction per DU cell (or recommendation per MT serving cell) including the associated parameters and conditions. A 2nd MAC CE indication overrides 1st MAC CE indication, including the associated parameters and conditions.

Agreement

The start RB index of the first RB set for the Rel-17 IAB-DU HSNA resource configuration is the lowest index of RB of the IAB-DU cell.

Agreement

Enhance the RRC signaling for the configuration of DCI Format 2_5 to include the configuration of availability indication for soft resources in multiple RB set groups by introducing the following new RRC parameters:

• AvailabilityCombination-Rel17 to include multiple resourceAvailaibity-Rel17 indications, where each resourceAvailaibity-Rel17 indicates the availability of soft resources in one or multiple slots for each configured RB set group in sequence. 
• The RB set groups are configured for all availabilityCombinationId(s) with the following parameters and are applied over each slot:
• Number of RB set groups.
• FFS: max value
• Number of RB sets for each group.
• FFS: max value
• If an RB set group is not provided, only one resourceAvailablity-Rel17 is included in AvailabilityCombination-Rel17 to indicate availability of soft resources in one or multiple slots for all RB sets of a DU cell.
• [One resourceAvailability-Rel17 element of the availabilityCombinations table is reserved to signal to the IAB-DU that “No new Availability Indication is provided” in DCI format 2_5 for slots which receive multiple Availability Indicators.]

R1-2202818        Feature Lead Summary #3 of 8.10.1           Moderator (AT&T)

From Mar 1^st GTW session

Agreement

For the RRC signaling for the configuration of DCI Format 2_5

·        Number of RB set groups has a max value of [8] within a slot.

·        Number of RB sets for each group has a max value of [8].

Decision: As per email decision posted on Mar 1^st,

Agreement

The following text proposal for IAB-DU behavior in case of a restricted beam indication for 38.213 is endorsed for the editor’s CR.

Agreement

The following text proposal for DCI Format 2_5 reception in inter-donor and intra-donor DC scenarios for 38.213 is endorsed for the editor’s CR.

Conclusion

Defer discussion (contribution driven) about extending the maximum payload size of DCI format 2_5 to increase the number of IAB-DU cells that can be provided with availability information for soft resources until RAN1#109-e.

Conclusion

Defer discussion (contribution driven) of potential issues/solutions for multiple DCI Format 2_5 indications with overlapping durations until RAN1#109-e.

Decision: As per email decision posted on Mar 2^nd,

Agreement

The following text proposal to capture RAN1#108-e agreements on extension of CA TDD prioritization rules to NR DC for IAB nodes is endorsed for the editor’s CR on TS38.213.

(clean version for reference)

R1-2202874        Feature lead summary #4 of 8.10.1             Moderator (AT&T)

Decision: As per email decision posted on Mar 4^th,

Conclusion

Defer discussion (contribution driven) about potential specification impact for conflict resolution between parent and child IAB nodes in case the Rel-17 H/S/NA configuration is provided but the IAB node needs to instead operate according to the Rel-16 H/S/NA configuration (based on its implementation as agreed previously in RAN1#107-e) in the slot until RAN#109-e.

Agreement

Adopt the following definition for H/S/NA configured in an RB set of a symbol:

·        FDM Hard: When an RB set of a downlink, uplink, or flexible symbol is configured as hard, the IAB-DU cell can respectively transmit, receive, or either transmit or receive on the RB set in the symbol [provided it does not impact the IAB-MT’s ability to transmit and receive in any other RB set that is configured as Not Available or configured as Soft and not indicated available].

·        FDM Soft: When an RB set of a downlink, uplink, or flexible symbol is configured as soft, the IAB-DU cell can respectively transmit, receive or either transmit or receive on the RB set in the symbol only if

o   the IAB-MT does not transmit or receive on the RB set during the symbol of the IAB-DU cell, or

o   with respect to all serving cells,

§  the IAB-MT would transmit or receive on the RB set during the symbol of the IAB-DU cell, and the transmission or reception on the RB set [or any adjacent RB set that is configured as Not Available or configured as Soft and not indicated available] during the symbol of the IAB-DU cell is not changed due to a use of the RB set in the symbol by the IAB-DU, or

o   if the IAB-MT is not configured with SCG

§  if the IAB-MT detects a DCI format 2_5 with an AI index field value indicating the soft RB set as available

o   if the IAB-MT is configured with SCG

§  the IAB-MT detects two DCI formats 2_5 with an AI index field value indicating the soft RB set as available from MCG and SCG respectively, or

§  the IAB-MT detects a DCI format 2_5 with an AI index field value indicating the soft symbol RB set as available from one cell group (either MCG or SCG), and, with respect to all serving cells of the other cell group:

·        the IAB-MT would transmit or receive on the RB set during the symbol of the IAB-DU cell, and the transmission or reception on the RB set during the symbol of the IAB-DU cell is not changed due to a use of the RB set in the symbol by the IAB-DU.

·        FDM NA: When an RB set of a downlink, uplink, or flexible symbol is configured as unavailable, the IAB-DU neither transmits nor receives at the RB set in the symbol.

Conclusion

Defer discussion (contribution driven) about potential specification impact if the configured RB sets of an IAB-DU HSNA resource configuration do not cover the entire carrier bandwidth until RAN1#109-e.

8.10.2     Other enhancements for simultaneous operation of IAB-node’s child and parent links

Including IAB-node timing mode(s), extensions for DL/UL power control, and CLI and interference measurements of BH links, as needed.

R1-2200927         Remaining issues on enhancements for simultaneous operation of MT and DU               Huawei, HiSilicon

R1-2201110         Remaining issues on other enhancements for simultaneous operation of child and parent links          vivo

R1-2201457         Enhancements for simultaneous operation of child and parent links        ZTE, Sanechips

R1-2201493         Remaining issues on IAB timing mode          NTT DOCOMO, INC.

R1-2201527         Enhancements to Timing, Power Control and CLI for NR IAB Samsung

R1-2201615         Discussion on eIAB simultaneous operation maintenance         ETRI

R1-2201674         Other enhancements for simultaneous operation of IAB-node’s child and parent links               Nokia, Nokia Shanghai Bell

R1-2201714         Other Enhancements for Simultaneous Operation of IAB          Intel Corporation

R1-2202157         Remaining issues on enhancements for simultaneous operation of IAB-node's child and parent links   Qualcomm Incorporated

R1-2202306         Discussions on other enhancement for simultaneous operation LG Electronics

R1-2202403         Timing in enhanced IAB   Ericsson

[108-e-R17-eIAB-02] – Luca (Qualcomm)

Email discussion on other enhancements for simultaneous operation of IAB-node’s child and parent links

-        1^st check point: February 25

-        Final check point: March 3

Decision: As per email decision posted on Feb 25^th,

Agreement

The desired MT UL PSD range is indicated via a max value, Pmax, and an offset to the max value.

·        The offset is indicated in the range of 0…10 dB

·        The range of max value, Pmax, is (-60..50) dBm.

Agreement

Support “slot index” indication in the desired UL PSD range indication.

R1-2202670        FL summary #1 of [108-e-R17-eIAB-02]   Moderator (Qualcomm Incorporated)

Decision: As per email decision posted on Feb 25^th,

Agreement

Extend the range of T_delta in the Timing Delta MAC CE to (0,1,…,2047).

Agreement

For Case 7 UL timing, the IAB-MT advances its uplink timing (relative to its DL RX timing) by T_TA + N_TA,offset,2 · T_c, where T_TA is obtained as for a UE in clause 4.3.1 of TS38.211, and N_TA,offset,2= T_offset,2 · 16 · 64/2^µ, and T_offset,2 is provided (by MAC-CE) in the range of (-3072, 1023).

Decision: As per email decision posted on Feb 28^th,

Agreement

The desired/provided DL TX power adjustment can be indicated with 5 bits and a 1 dB resolution.

·        FFS endpoints of the range

Agreement

“MT’s DL beam” (and “MT’s UL beam”) indication, associated with an MT CC, in a desired/provided DL TX power adjustment (and desired UL PSD range indication) can provide a list of up to 8 beams.

Decision: As per email decision posted on Mar 1^st,

Agreement

An IAB-node can assume that the T_delta value for IAB-MT Tx Case 7 timing is the same as for IAB-MT Tx Case 1 Tx timing.

Conclusion

In Rel-17 T_delta MAC-CE is not extended to indicate the timing case associated with the signalled T_delta value.

R1-2202831        FL summary #2 of [108-e-R17-eIAB-02]   Moderator (Qualcomm)

From Mar 2^nd GTW session

Agreement

The following TP is endorsed for the editor’s CR

----- Start of TP to 38.213 Clause 14 -----

<Unchanged text is omitted>

If an IAB-node is provided an index  in a Timing Delta MAC CE [11, TS 38.321] from a serving cell, the IAB-node may assume that   is a time difference between a DU transmission of a signal from the serving cell and a reception of the signal by the IAB-MT when  , where:

-          for transmission timing mode ‘Case 6’ is defined as the difference between the IAB-MT reception time and the IAB-MT transmission time, and, for transmission timing modes ‘Case1’ and ‘Case7’ is defined in clause 4.3.1 of [4, TS38.211],

-         and  and  are determined as:

-          and , if the serving cell providing the Timing Delta MAC CE operates in FR1,

-          and , if the serving cell providing the Timing Delta MAC CE operates in FR2.

<Unchanged text is omitted>

----- End of TP to 38.213 Clause 14 -----

Conclusion

There is no consensus in RAN1 on support of the following proposal in Rel-17:

An IAB-node can provide to its parent via MAC-CE the MT Tx timing offset between Case 1 and Case 6 timing.

Agreement

The IAB-MT shall account for the provided DL TX power adjustment (as indicated by the parent-node) in addition to Pc when deriving CSI feedback.

Agreement

RAN1 to send an LS to RAN4 including:

·        Informing RAN4 that the information of basic PSD difference is not needed, and

·        FFS: asking what is the impact of IAB-MT if the transmit power of parent IAB-DU exceeds basic PSD difference.

·        FFS: asking what should be considered for the range of DL TX adjustment (at the parent-node), when the IAB-MT is the only recipient, and the DL Tx power is constant within a slot.

·        FFS: whether guard symbols are required to support a DL TX power adjustment.

·        FFS: clarifying that the desired/provided DL TX power adjustment is applicable only to PDSCH and its associated DMRS and PTRS and is indicated in terms of a relative offset to a CSI-RS TX power.

R1-2200906        LS on range of power control parameters for eIAB              RAN4, Samsung

R1-2202877        Reply LS on range of power control parameters for eIAB   RAN1, Samsung

Decision: As per email decision posted on Mar 3^rd, the reply LS to RAN4 is approved.

8.10.33     Other

R1-2201458         Remaining issue on higher layers parameter list for Rel-17 IAB              ZTE, Sanechips

R1-2202404         Higher layer parameters (RRC, MAC-CE, F1AP, XnAp) for enhanced IAB               Ericsson

R1-2202422         Other enhancements for IAB           Huawei, HiSilicon

 RAN1#109-e

8.100   Maintenance on Enhancements to Integrated Access and Backhaul

R1-2205282        Summary of [109-e-Prep-AI8.10-eIAB]     Moderator (Qualcomm)

R1-2203078         Remaining issues on R17 IAB enhancements              Huawei, HiSilicon

R1-2203353         Maintenance on Enhancements to Integrated Access and Backhaul        Nokia, Nokia Shanghai Bell

R1-2203359         Maintenance on enhancements to IAB           ZTE, Sanechips

R1-2203523         Maintenance on Enhancements to Integrated Access and Backhaul        vivo

R1-2203763         Discussions on enhancements to resource multiplexing between child and parent links of an IAB node         CEWiT

R1-2203871         Maintenance on Enhancements to NR IAB    Samsung

R1-2204351         Maintenance on Enhancements to Integrated Access and Backhaul        NTT DOCOMO, INC.

R1-2204413         Resource multiplexing in enhanced IAB systems        Lenovo

R1-2204528         Remaining details on enhancements to IAB  LG Electronics

R1-2204640         Maintenance on enhanced IAB        Ericsson

R1-2204648         Discussions on eIAB maintenance  ETRI

R1-2204777         Remaining details on Frequency-domain Resource Multiplexing for IAB             Intel Corporation

R1-2204992         Remaining issues on eIAB Qualcomm Incorporated

[109-e-R17-eIAB-01] – Luca (Qualcomm)

Issues #3, #11, #12, #15 in R1-2205249 by May 13

-        1^st check point: May 13

-        Final check point: May 20

-        RAN2 related issues to be finalized by 1^st check point

R1-2205283        Summary #1 of [109-e-R17-eIAB-01]         Moderator (Qualcomm)

From May 10^th GTW session

Agreement

RAN1 to inform RAN2 on the following in regard to the term “slot index” for the timing case in the context of the MAC-CEs Timing Case Indication, IAB-MT Recommended Beam Indication, Child IAB-DU Restricted Beam Indication, Desired DL Tx Power Adjustment, DL Tx Power Adjustment, and Desired IAB-MT PSD Range:

-        The term “slot index” indicates a list of slots.

Additionally, for the Timing Case Indication MAC-CE:

-        Each slot within the periodicity can be assigned a timing case value. Case 1 is considered the default.

-        RAN1 does not preclude that a large fraction of the slots in the periodicity may use a given timing case value.

Detailed MAC-CE design is up to RAN2.

Agreement

For the child IAB-DU Restricted Beam indication, only SSB or SSB+STC or CSI-RS is used for a given beam.

Agreement

Each recommended beam indication includes either a DL Rx beam or an UL Tx beam but not both.

Each recommended beam indication for a DL Rx beam includes either a TCI index or a SSB index or a CSI-RS index.

Issues #1, #2, #4, #5, #8 in R1-2205249 by May 13

-        1^st check point: May 13

-        Final check point: May 20

-        RAN2 related issues to be finalized by 1^st check point

R1-2205216        Email Discussion Summary #1 for [109-e-R17-eIAB-02]      Moderator (AT&T)

From May 10^th GTW session

Agreement

An IAB node can be configured with two availabilityCombinations tables, one for TDM and one for FDM.

R1-2205514        TP for TS38.213 on soft resource availability for eIAB        Moderator (AT&T)

Decision: As per email decision posted on May 11^th,

Agreement

The text proposal in R1-2205514 for TS38.213 is endorsed for the editor’s CR.

R1-2205251        Email Discussion Summary #2 for [109-e-R17-eIAB-02]      Moderator (AT&T)

From May 12^th GTW session

Proposal:

·        Support optional MAC-CE signaling from child node to parent node to indicate switching between TDM/non-TDM multiplexing mode operation.

·        If both Rel-16 H/S/NA and Rel-17 H/S/NA are configured for a given resource:

o   If the child node is operating in non-TDM multiplexing mode,

§   it follows the Rel-17 H/S/NA configuration for the resource

o   If the child node is operating in TDM multiplexing mode and indicates switching from non-TDM to TDM multiplexing mode operation via MAC-CE,

§  it follows the Rel-16 H/S/NA configuration for the resource

o   If the child node is operating in TDM multiplexing mode and does not indicate switching from non-TDM to TDM multiplexing mode operation via MAC-CE,

§  a resource configured with Rel-16 H or Rel-16 S with dynamic indication of availability overrides the Rel-17 H/S/NA configuration, otherwise it follows the Rel-17 H/S/NA configuration for the resource

Objections: Huawei/HiSilicon, ETRI, ZTE

Conclusion

There is no consensus in RAN1 on the support of optional MAC-CE signaling from child node to parent node to indicate switching between TDM/non-TDM multiplexing mode operation.

R1-2205515        TP for TS38.214 on CSI feedback for eIAB             Moderator (AT&T)

Decision: As per email decision posted on May 17^th,

Agreement

The text proposal in R1-2205515 on CSI feedback accounting for provided power adjustment is endorsed for editor’s CR for TS38.214.

Agreement

If an IAB node is configured with two availabilityCombinations tables, both shared and separate AI index fields are supported by introducing positioninDCI-AI-rel17.

Agreement

If the RB sets of a Rel-17 IAB-DU H/S/NA resource configuration do not cover the entire carrier bandwidth, the remaining RBs not part of an RB set configuration are considered as included in the last RB set.

Decision: As per email decision posted on May 21^st,

Conclusion

If both Rel-16 H/S/NA and Rel-17 H/S/NA are configured for a given resource and the child node is operating in TDM multiplexing mode, consider the following alternatives until RAN1#110:

·        Alt. 1: the child node follows the Rel-16 H/S/NA configuration for the resource

·        Alt. 2: the child node follows the Rel-17 H/S/NA configuration for the resource

·        Alt. 3: A resource configured with Rel-16 H or Rel-16 S with dynamic indication of availability overrides the Rel-17 H/S/NA configuration, otherwise the child node follows the Rel-17 H/S/NA configuration for the resource

·        Alt. 4 the child node follows the Rel-16 or Rel-17 H/S/NA based on implicit indication (e.g. Case 6 timing indication) between parent and child node.

Conclusion

Consider until RAN1#110 whether additional specification is required when FDM multiplexing mode is applied for the CSI reference resource.

Conclusion

Consider until RAN1#110 the following solutions to increase the number of IAB-DU cells that can be provided with availability information for soft resources:

·        Alt. 1. extension of DCI format 2_5 payload from 128 bits to 134 bits

·        Alt. 2. Mapping the bits of an availabilityIndicator to one or multiple cells

R1-2205516        [Draft] LS on upper layers parameters for Rel-17 eIAB      Moderator (AT&T)

Decision: As per email decision posted on May 21^st, the draft LS is endorsed. Approved in R1-2205517.

Further revised by MCC to fix LS header issues:

R1-2205644        LS on upper layers parameters for Rel-17 eIAB     RAN1, AT&T

Issues #6, #7, #9, #10, #13, #14, #16 in R1-2205249 by May 20

-        This email discussion is to start on May 16

R1-2205284        Summary #1 of [109-e-R17-eIAB-03]         Moderator (Qualcomm)

R1-2205552        Endorsed TPs to TS 38.213 for Rel-17 eIAB            Moderator (Qualcomm)

Decision: As per email decision posted on May 19^th,

Agreement

·        The text proposal in R1-2205552 (under 3.1) is endorsed for the editor’s CR for clause 14 of TS38.213.

·        The text proposal in R1-2205552 (under 3.2) is endorsed for the editor’s CR for clause 14 of TS38.213.

·        The first text proposal in R1-2205552 (under 3.4) is endorsed for the editor’s CR for clause 14 of TS38.213:

Decision: As per email decision posted on May 20^th,

Agreement

·        The second text proposal in R1-2205552 (under 3.4) is endorsed for the editor’s CR for clause 14 of TS38.213:

Conclusion

In Rel17, there is no additional specification for handling of multiple DCI Format 2_5 indications with overlapping durations.

Agreement

·        The text proposal in R1-2205552 (under 3.3) is endorsed for the editor’s CR for clause 14 of TS38.213:

Decision: As per email decision posted on May 22^nd,

Agreement

The following RAN1#108-e agreement is amended as:

// LS from RAN2 (handled under [109-e-R17-eIAB-01])

R1-2205250        LS on eIAB MAC CEs     RAN2, Samsung

R1-2205302        Discussion on reply LS on eIAB MAC CEs              Moderator (Qualcomm Incorporated)

R1-2205292        [Draft] Reply LS on eIAB MAC CEs          Moderator (Qualcomm)

Decision: As per email decision posted on May 14^th, the draft reply LS is endorsed. Approved in R1-2205293.

 RAN1#110

8.100   Maintenance on Enhancements to Integrated Access and Backhaul

[110-R17-IAB] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Luca (Qualcomm)

R1-2205808         Correction on TDD configuration for IAB-MT            Huawei, HiSilicon

R1-2206202         Corrections on misalignment for MAC CE or RRC parameters for eIAB in TS 38.213               ZTE, Sanechips

R1-2206203         Correction on the formula of Case-7 UL Tx timing for eIAB in TS 38.213               ZTE, Sanechips

R1-2206204         Correction on the position related to the description that the RB set is equivalent to hard for eIAB in TS 38.213             ZTE, Sanechips

R1-2206205         Correction on coexistence between Rel-16 and Rel-17 H/S/NA configuration               ZTE, Sanechips

R1-2206206         Discussion on coexistence between Rel-16 and Rel-17 H/S/NA configuration               ZTE, Sanechips

R1-2206508         Resource multiplexing in enhanced IAB systems        Lenovo

R1-2206561         Remaining Issues on Frequency-domain Resource Multiplexing for IAB              Intel Corporation

R1-2206803         Maintenance on Enhancements to NR IAB    Samsung

R1-2206950         Discussions on eIAB CSI  ETRI

R1-2206951         Draft CR on eIAB CSI       ETRI

R1-2207204         Draft CR on eIAB              Qualcomm Incorporated

R1-2207205         Remaining issues on eIAB Qualcomm Incorporated

R1-2207373         On Handling for Rel-16 and Rel-17 Resource Configuration Conflicts   Nokia, Nokia Shanghai Bell

R1-2207521         Remaining issues on resource multiplexing for IAB    Huawei, HiSilicon

R1-2207522         Correction on CQI derivation accounting for provided DL Tx power adjustment for IAB-MT Huawei, HiSilicon

R1-2207665         Correction on HSNA resource configuration for IAB  Huawei, HiSilicon

R1-2207674         Draft CR on DL Tx power control  Ericsson

R1-2207675         Discussion on DL Tx power control              Ericsson

R1-2207676         Draft CR on guard symbols MAC CEs          Ericsson

R1-2207677         Draft CR on timing case indication Ericsson

R1-2207678         Draft CR on Hard/Soft/Not Available resource definition         Ericsson

R1-2207679         Maintenance on enhanced IAB        Ericsson

R1-2207946        Summary 1 of [110-R17-IAB]       Moderator (Qualcomm)

Working Assumption

If Rel-16 H/S/NA resource configuration and Rel-17 H/S/NA resource configuration are both provided for a given RB set within a slot:

·        Alt 3b. A resource configured with Rel-16 H or Rel-16 S with dynamic indication of availability overrides the Rel-17 H/S/NA configuration, otherwise the child node follows the Rel-17 H/S/NA configuration for the resource.

Agreement

Support [-15, 5] for the range of DL Tx power adjustment.

Agreement

·        Endorse TP in R1-2207522 for TS 38.214.

Final CR (38.214, Rel-17, CR#0308, Cat F) is agreed in:

R1-2208053        Correction on CQI derivation accounting for provided DL Tx power adjustment for IAB-MT        Moderator (Qualcomm), Huawei, HiSilicon

MCC: To correct WI code to NR_IAB_enh-Core in R1-2208053.

Agreement

·        Endorse TP in R1-2206951 for TS 38.214. Final CR in R1-2208054.

Final CR (38.214, Rel-17, CR#0309, Cat F) is agreed in:

R1-2208054        CR on eIAB CSI Moderator          (Qualcomm), ETRI

From AI 5

R1-2205705        LS on RB set configuration for IAB           RAN3, Huawei

R1-2207956        Summary 1 of discussion on IAB rely LS for R1-2205705    Moderator (Huawei)

Agreement

For RAN3 LS in R1-2205705, the following response is agreed.

-        Question 1: Whether the RB set needs to be configurable to the IAB-donor-DU?

o   Answer: No. From RAN1 point of view, the RB set configuration is not applicable to IAB-donor-DU

-        Question 2: Whether the current F1AP signalling about RB set size is clear enough. If not, which kind of clarification should be added?

o   Answer: RAN1 was not available to converge on a response. Existing RAN1 agreements with reference to F1AP signalling about RB set size is unchanged.

R1-2208220        Draft reply LS on RB set configuration for IAB     Huawei

Decision: The draft LS is endorsed. Final LS is approved in R1-2208221.

 RAN1#110-bis-e

8.100   Maintenance on Enhancements to Integrated Access and Backhaul

[110bis-e-R17-eIAB-01] – Luca (Qualcomm)

Email discussion to determine maintenance issues to be handled in RAN1#110bis-e by October 12

-        Additional email discussions will be set up once the maintenance issues for RAN1#110bis-e are determined

R1-2210796        Summary #1 of [110bis-e-R17-eIAB-01]    Moderator (Qualcomm Incorporated)

R1-2208471         Remaining issues on resource multiplexing for IAB    Huawei, HiSilicon

R1-2208787         Correction on the position related to the description that the RB set is equivalent to hard for eIAB in TS 38.213             ZTE, Sanechips

R1-2209084         Correction on RB set size for Rel-17 IAB FDM multiplexing   Nokia, Nokia Shanghai Bell

R1-2209118         Resource multiplexing in enhanced IAB systems        Lenovo

R1-2209834         Correction on coexistance between Rel-16 and Rel-17 H/S/NA configuration               Huawei, HiSilicon

R1-2209835         Correction on TDD configuration for IAB-MT            Huawei, HiSilicon

R1-2209949         Draft CR on FD and TD DU resource configuration coexistence            Qualcomm Incorporated

R1-2210170         Clarification on Rel-16 and Rel-17 H/S/NA Configuration       Nokia, Nokia Shanghai Bell

R1-2210225         Draft CR on DL Tx power control  Ericsson

R1-2210226         Discussion on DL Tx power control              Ericsson

R1-2210228         Draft CR on timing case indication Ericsson

R1-2210230         Maintenance on enhanced IAB        Ericsson

[110bis-e-R17-eIAB-02] – Luca (Qualcomm)

Email discussion on remaining eIAB maintenance issues by October 17

-        Topic #1. Coexistence of TD and FD DU resource configurations

-        Topic #2. Corrections on RB set size for Rel-17 IAB FDM multiplexing

-        Topic #4. Correction on the formula of Case-7 UL Tx timing for eIAB in TS 38.213

-        Topic #5. Additional specification for DL Tx power adjustment

-        Topic #8. Draft CR on guard symbols MAC CEs

-        Topic #9. Draft CR on timing case indication

-        Topic #11. Handling of interference between adjacent RB sets in FDM operation

-        For alignment CRs: Topic #6 (R1-2208788), Topic #7 (R1-2208787), Topic #10 (R1-2210229)

R1-2210797        Summary #1 of [110bis-e-R17-eIAB-02]    Moderator (Qualcomm Incorporated)

Decision: As per email decision posted on Oct 17th,

R1-2208786        Correction on the formula of Case-7 UL Tx timing for eIAB in TS 38.213               ZTE, Sanechips

Agreement

·        Correction on the formula of Case-7 UL Tx timing for eIAB for TS 38.213 (R1-2208786) is endorsed.

Final CR (TS 38.213, Rel-17, CR#0392, Cat F) is agreed in:

R1-2210706        Correction on the formula of Case-7 UL Tx timing for eIAB in TS 38.213               Moderator (Qualcomm), ZTE, Sanechips

R1-2210227        Draft CR on guard symbols MAC CEs      Ericsson

Agreement

·        Correction on the guard symbols MAC CEs for TS 38.213 (R1-2210227) is endorsed.

Final CR (TS 38.213, Rel-17, CR#0393, Cat F) is agreed in:

R1-2210707        CR on guard symbols MAC CEs  Moderator (Qualcomm), Ericsson

R1-2210229        Draft CR on Hard/Soft/Not Available resource definition   Ericsson

For the editors:

The text proposal for TS38.213 in R1-2210229 is provided to improve the clarity of the RAN1 specifications. Please include it in the alignment CR.

Agreement

·        Adopt the following TP in clause 14 of TS38.213:

Final CR (TS 38.213, Rel-17, CR#0394, Cat F) is agreed in:

R1-2210756        Correction on timing case indication          Moderator (Qualcomm), Ericsson, ZTE, Sanechips

Decision: As per email decision posted on Oct 18th,

Agreement

·        Confirm the WA from RAN1#110:

Final CR (TS 38.213, Rel-17, CR#0395, Cat F) is agreed in:

R1-2210757        Correction on on coexistence of Rel-17 and Rel-16 HSNA configuration               Moderator (Qualcomm)

R1-2208788        Corrections on misalignment for MAC CE or RRC  parameters for eIAB in TS 38.213   ZTE, Sanechips

For the editors:

The following corrections 1, 2, 4, and 5 in R1-2208788 on parameters name misalignment for TS 38.213 is provided to improve the clarity of the RAN1 specifications. Please include them in the alignment CR.

 RAN1#111

8.100   Maintenance on Enhancements to Integrated Access and Backhaul

[111-R17-IAB] – Luca (Qualcomm)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2211305         Correction on RB set size for Rel-17 IAB FDM multiplexing   Nokia, Nokia Shanghai Bell

R1-2212022         Maintenance on Enhancements to NR IAB    Samsung

R1-2212087         Draft CR on correction on RB set size for Rel-17 IAB FDM     Qualcomm Incorporated

R1-2212200         Correction on RB set size for an IAB-DU cell             ZTE, Sanechips

R1-2212201         Correction on DL TX power adjustment for eIAB in TS 38.213              ZTE, Sanechips

R1-2212338         Draft CR on DL Tx power control  Ericsson

R1-2212339         Discussion on DL Tx power control              Ericsson

R1-2212340         Draft CR on RB set size    Ericsson

R1-2212341         Maintenance on enhanced IAB        Ericsson

R1-2212481         Remaining issues on resource multiplexing for IAB    Huawei, HiSilicon

R1-2212482         Correction on coexistence between Rel-16 and Rel-17 H/S/NA configuration               Huawei, HiSilicon

R1-2212804        Feature lead summary for Maintenance on eIAB   Moderator (Ericsson)

Agreement:

1.      RAN1 to amend the agreement from RAN1#110 as:

Additionally support [6, 15] dB for the range of DL TX power adjustment.

2.      RAN1 to agree to the following TP for inclusion in TS 38.213.

The PDSCH EPRE can be derived from a downlink CSI-RS EPRE as described in [6, TS 38.214] and a power offset provided by DL Tx Power adjustment field in DL TX Power Adjustment MAC CE as described in [11, TS 38.321]. The downlink CSI-RS EPRE refers to the CSI-RS indicated by Reference CSI-RS ID in DL Tx Power Adjustment MAC CE as described in [11, TS 38.321]. The DL TX Power Adjustment provides the offset between PDSCH EPRE and CSI-RS EPRE.

Final CR:

R1-2212940        Correction on DL TX power adjustment for Rel-17 IAB     Moderator (Ericsson), ZTE, Sanechips, Samsung, Lenovo, Huawei, HiSilicon

Decision: As per decision on Nov 18th, (Rel-17, TS 38.213, CR#0431,Cat F) is agreed.

Conclusion:

DL TX power adjustment does not apply to a slot where a Rel-16 TDM resource configuration is applied.

Agreement:

RAN1 to agree to the following text proposal for inclusion in TS 38.213:

“The IAB-node can assume the RB set size for the IAB-DU cell is larger than or equal to the IAB-MT’s smallest RBG size of the configured BWPs of the FDM required IAB-MT’s serving cell as indicated in Multiplexing Info [16,TS 38.473] of the DU cell.”

Final CR:

R1-2212939        Correction on RB set size for Rel-17 IAB HSNA configuration         Moderator (Ericsson), ZTE, Sanechips, Nokia, NSB, Samsung, Lenovo, Huawei, HiSilicon

Decision: As per decision on Nov 18th, (Rel-17, TS 38.213, CR#0430,Cat F) is agreed.

Agreement:

·        If only Rel-16 time-domain H/S/NA configuration is provided, the availabilityCombinations-r16 is used for dynamic indication of availability.

o   The IAB-MT ignores the dynamic indication of availability based on availabilityCombinations-r17 for this slot.

 RAN1#112

8.100   Maintenance on Enhancements to Integrated Access and Backhaul

[112-R17-IAB] – Luca (Qualcomm)

To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

From AI 5

R1-2300006        LS on RB set configuration           RAN3, ZTE

R1-2302005        Summary of reply LS to R1-2300006 (RAN3 LS on RB set configuration)               Moderator(ZTE)

R1-2302128        Summary#2 of reply LS to R1-2300006 (RAN3 LS on RB set configuration)               Moderator (ZTE)

From Friday session

Agreement

Confirm with RAN 3 that the following understanding is correct:

n  Modified understanding 2: the start RB index for the Rel-17 IAB-DU HSNA resource configuration of the IAB-DU cell is the RB index of the lowest common RB with the reference SCS, which overlaps with the lowest usable RB  across all SCS-specific carriers provided by the NR Carrier List IE for this cell.

Send an LS to RAN3.

R1-2302129        Draft reply LS on RB set configuration     Moderator (ZTE)

Decision: The draf LS is endorsed. Final LS is approved in R1-2302130.

R1-2300134         Remaining issues on resource multiplexing for IAB    Huawei, HiSilicon

R1-2300774         Draft CR Regarding IAB Availability Combinations  Nokia, Nokia Shanghai Bell

R1-2301237         Maintenance on Enhancements to NR IAB    Samsung

R1-2301719         Correction on dynamic indication of availability for IAB          Huawei, HiSilicon

R1-2301761         Correction on TDM/FDM H/S/NA switching in eIAB Ericsson

R1-2301762         Discussion on TDM/FDM H/S/NA switching in eIAB              Ericsson

R1-2301763         Correction on availability indication in eIAB               Ericsson

R1-2301998        Summary of [112-R17-IAB]          Moderator (Qualcomm)

From Tuesday session

Agreement

When both AvailabilityCombinations-r16 and availabilityCombinationsRB-Groupsr17 are configured, DCI 2_5 indexes both AvailabilityCombinations-r16 and availabilityCombinationsRB-Groupsr17.

R1-2302107        Summary#2 of [112-R17-IAB]      Moderator (Qualcomm)

From Friday session

R1-2300775        Draft CR editorial correction on IAB RRC parameters       Nokia, Nokia Shanghai Bell

Agreement

·        Adopt TP in R1-2300775 for TS38.213. Final CR (Rel-17, 38.213,CR0456, Cat F) is agreed in

R1-2302216        CR editorial correction on IAB RRC parameters   Moderator (Qualcomm), Nokia, Nokia Shanghai Bell, Ericsson

R1-2301081        Correction on the availability of a soft RB set in an RB set group in TS 38.213               ZTE, Sanechips

Agreement

·        Endorse draft CR in R1-2301081 for TS38.213. Final CR (Rel-17, 38.213,CR0457, Cat F) is agreed in

R1-2302217        Correction on the availability of a soft RB set in an RB set group in TS 38.213   Moderator (Qualcomm), ZTE, Sanechips

R1-2302199        DRAFT Correction on availability indication for eIAB        Moderator (Qualcomm)

Agreement

·        Endorse draft CR in R1-2302199 for TS38.213. Final CR (Rel-17, 38.213,CR0455, Cat F) is agreed in

R1-2302215        Correction on availability indication for eIAB        Moderator (Qualcomm), Huawei, HiSilicon, Ericsson